S/MIME revocation lists signed by different CA?

[Bernhard Reiter]

Am Mittwoch, 4. August 2010 10:50:08 schrieb Werner Koch:
> On Mon,  2 Aug 2010 22:14, bernhard at intevation.de said:
> > both roots are trusted, somehow I still would expect
> > dirmngr to reject the A certificate because the CRL
> > was not signed by CA A, the same authority that issued it.
>
> The whole X.509 system has deployed today does not use a single root CA,
> as it was designed to, but the IUCC [1] system where all root
> certificates you trust make up one giant virtual single root CA. 

> [1] Implicy Universal Cross-Certification

Is that IUCC a widespead term? I have not found more information about it.
One minor assumption I would make is that the cross trust between
the roots and their respective certification trees is a bit less
than within one tree alone. If this is assumption is not made so far,
it looks like a sensible and useful assumption to me.

> Thus it doesn't matter which root CA issued the CRL.
>
> Of course we could check that a specific CRL has been signed by a CA
> which ultimately is anchored at the root CA which issued the certificate
> you want to check with the CRL.  This would be another exception to the
> complicated X.509 system but of course doable.  I doubt that this is
> really useful.  What is the threat model?  Another CA would be able to
> revoke a certificate - Is that actually more harmful than this other CRL
> issuing a fake certificate?  I doubt that.

Okay, we have two thread models so far
a) revoke valid certificates and render services unavailable based on them
b) resurrected revoked certificates (as Bernd Eckenfels pointed out) which 
   might make services attackable if certificates were compromissed before.

I believe there is value in both attacks.

And they are quite likely to be performed even without compromising a 
different CA, if I am right about that there is no strong connection between 
the signed CRL and the CA itself now.
(My openssl crl -text and openssl as1nparse output of a CRL did not show
any indication that the CRL is signed for a specific CA as it is not 
contained. Am I right? Otherwise how is the connection made?)

This would reduce the attack to finding any CRL 
with the right properties over all CRLs that the user already trusts.
For b) it will be easy for a) there needs to be a serial number revoked
that I need to attack (I am not absolutely sure, but I remember only the 
serial numbers to be listed). 
In a world with several root cas, there will be some serial number collisions
and lots of CRLs without serial numbers I might be interested in.

Then I just redirect the LDAP or HTTP request, e.g. by DNS manipulation
to the other CRL. Attack done.

Right now I cannot dive into the various X509 specs and profiles,
but assuming some of them make sense I would expect either finding how to 
couple CRL and sigining CAs or not allowing other CAs to sign the CRLs.

> IIRC, I once noticed a legitimate certificate which pointed to a CRL
> which was ultimately certified by a different root CA.  Exactly the
> case you described - do you want to break those certificates?

You only know if this a legitimate cert, 
if you trust the other root CA to make statements about it.
(See my minor assumption above.)

Best Regards,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100805/9a6613ea/attachment.pgp>