Subject: Re: WG Last Call: AIA CRL extension

From: Tom Gindin <[email-masked]>
Date: Tue, 24 May 2005 10:36:16 -0400

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".

                Tom Gindin

----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM -----

Tom Gindin
05/23/2005 10:46 PM

        To:     [email-masked]
        cc:     [email-masked], [email-masked], [email-masked], 
[email-masked]
        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 <[email-masked]>
Sent by: [email-masked]
05/10/2005 05:27 PM
 
        To:     [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        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

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 24 May 2005 17:56:58 +0200

Tom,

Thank you for bringing water to my mill. :-)

To respond to your previous e-mail, you said:

"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 saying that this case is secure.

Expending it to the certification tree, would need to demonstrate that it is 
secure, ... and this has not be yet done at the moment (in particular for 
the case of same DN for the CRL issuer name).

Denis

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 24 May 2005 18:38:58 +0200

> 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

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 24 May 2005 19:51:38 +0200

>a repository break-in and makes the "attack" even more realistic.
Or in a CMS messages, together with the certificates that validate it. 
The problem is not restricted to the AIA.

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 May 2005 14:28:42 -0400

Julien & Tom:

Two points:

1.  I understand this scenario.  The change that you advocate as a 
countermeasure will prevent Indirect CRLs from working in scenarios that 
are intended.

2.  This observation has noting to do with the CRL AIA extension.  The 
attacker is inserting the bogus revocation information into the 
repository.  Any relying party that uses that repository (when using the 
CRL AIA extension or any other configuration information to locate it) will 
get the bogus revocation information.

If this is a concern, then it needs to be addressed in RFC3280bis, not here.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 25 May 2005 09:46:31 +0200

Russ,

Two points:

1. The current text in the security considerations section contains
    text which suggest a solution to the problem but which is not.
    At least the two following sentences SHALL be deleted:

    " As means of reducing problems and security issues related to issuer
    name collisions, CA names SHOULD be formed in a way that reduce the
    likelihood of name collisions.  Implementations validating CRLs
    MUST ensure that the certification path of the target certificate
    and the CRL issuer certification path used to validate the target
    certificate, terminate at the same trust anchor".

2. We strongly agree that 3280bis MUST address this issue and currently
    it does not do it correctly (otherwise we would not have this
    loooong discussion), ... that we can continue within the scope
    of 3280bis.

Denis

> CRL AIA extension or any other configuration information to locate it) 
> will get the bogus revocation information.
>