Stefan Santesson
Program Manager, Standards Liaison
Windows Security
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Denis Pinkas
Sent: den 25 maj 2005 00:47
To: Russ Housley
Cc: ietf-pkix@xxxxxxx
Subject: Re: WG Last Call: AIA CRL extension
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
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
At 12:38 PM 5/24/2005, Julien Stern wrote:
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: 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