Re: WG Last Call: AIA CRL extension

["Julien Stern" <[e-mail]>]

On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> 
>         There is one scenario permitted by the "same trust anchor" rule 
> for CRL signers which seems to me to be a serious security hole.  Let us 
> assume a valid CA which is a direct subordinate of one of the RP's trust 
> anchors.  This CA issues separate CRL's and ARL's, in a quite usual way, 
> and issues cross certificates.  After months or years of operation, it 
> revokes one of its cross certificates because the subject's operator has 
> gone rogue.  That rogue subject then issues a fraudulent CRL Signing 
> certificate with the DN that the superior certificate has been using to 
> sign ARL's, a public key which it has newly generated, and various 
> extensions including an SKID.  It then issues an updated copy of an old 
> ARL under the fraudulent CRL signer's certificate and with an AKID 
> matching the fraudulent signer's SKID.  If the rogue can break into the 
> repository where the CRL is expected, this fraudulently issued CRL will 
> probably be validated whether it contains an AIA or not.  It will 
> certainly pass the "same trust anchor" condition.
>         This scenario, in which a rogue CA issues an ARL certifiying that 
> its primary certificate has not been revoked and gets the ARL accepted, is 
> possible under "same trust anchor" but not under "signed by path member".

I agree with the validity of this scenario. I believe this is very
close to the issue I attempted to bring on the list a short time ago.
Of course, it assumes the existence of a rogue CA at some point in time.

Note that the CRL could be directly inserted into a "long term"
signature (according to RFC3126 for example). This does not require
a repository break-in and makes the "attack" even more realistic.

Regards.

--
Julien Stern

> 
>                 Tom Gindin
> 
> ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM -----
> 
> 
> Tom Gindin
> 05/23/2005 10:46 PM
> 
>         To:     [e-mail]
>         cc:     [e-mail], [e-mail], [e-mail], 
> [e-mail]
>         From:   Tom Gindin/Watson/IBM@IBMUS
>         Subject:        Re: WG Last Call: AIA CRL extension
> 
>         Tim:
> 
>         I should probably have brought this up earlier, but are we certain 
> that "same trust anchor" is a strong enough check that the CRL signer is 
> the one expected by the issuing CA?  While I was not in San Diego when 
> this wording was included in the 3280 series, I do not really think that 
> that check is strong enough.  I would suggest instead that the CRL 
> signer's certificate needs to be directly issued by one of the CA's in the 
> certification path back to the trust anchor used for the certificate's 
> verification, or by that anchor itself, unless people have practical 
> experience with CA structures which that rule would prohibit.  Forcing the 
> CRL to be issued by the CA itself (as I understand Denis to have 
> suggested) prohibits the reasonable case where the CRL is issued by a 
> hierarchical superior, so it is IMHO too strict.
>         I am personally not sure, FWIW, that a CRL should be permitted to 
> be signed by a second-cousin certificate of the issuer's certificate.  By 
> analogy to the use of the terms in families, "sibling" certificates would 
> have the same issuer, "first-cousin" certificates would be issued by 
> siblings, and "second-cousin" certificates would be issued by first 
> cousins - so they are both three levels down from the same trust anchor, 
> or from the last common CA in their paths.  This issue is not newly caused 
> by CRL AIA, since the same issue can arise with CRL's containing only 
> AKID.  AIA only allows RP's to build a path (whether right or wrong) more 
> quickly.
>         In any case, nothing more than a note in Security Considerations 
> is appropriate in any of our RFC's other than 3280 and its successor.
> 
>         Tom Gindin
> P.S. -  The above views are mine, and not necessarily those of my employer
> 
> 
> 
> 
> 
> Tim Polk <[e-mail]>
> Sent by: [e-mail]
> 05/10/2005 05:27 PM
>  
>         To:     [e-mail]
>         cc:     [e-mail], [e-mail], [e-mail]
>         Subject:        WG Last Call: AIA CRL extension
> 
> 
> 
> 
> This message initiates working group Last Call for the specification 
> "Internet X.509 Public Key Infrastructure: Authority Information Access 
> CRL 
> Extension".  While some issues raised in the working group are unresolved, 
> 
> the editors believe that rough consensus supports the current 
> specification.
> 
> The URL for this Internet-Draft is:
>                  
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not 
> close before May 24.
> 
> Thanks,
> 
> Tim Polk 
> 
> 
>