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: wpolk@xxxxxxxx
cc: housley@xxxxxxxxxxxx, ietf-pkix@xxxxxxx, kent@xxxxxxx,
stefans@xxxxxxxxxxxxx
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 <tim.polk@xxxxxxxx>
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
05/10/2005 05:27 PM
To: ietf-pkix@xxxxxxx
cc: kent@xxxxxxx, stefans@xxxxxxxxxxxxx, housley@xxxxxxxxxxxx
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