RE: WG Last Call: AIA CRL extension

["Stefan Santesson" <[e-mail]>]

Tom and Julien,

Since this is a repetition of the discussion we had before San Diego and
I don't want to repeat it here. I'm not saying that this discussion is
invalid; it is just directed towards the wrong draft. 

As Tom pointed out:
> this fraudulently issued CRL will probably be validated whether it 
> contains an AIA or not.

This indicates once again that this is not an issue caused by the use of
AIA in CRLs but a generic CRL validation issue that belongs with RFC
3280bis and not with the CRL-AIA draft.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Julien Stern
> Sent: den 24 maj 2005 09:39
> To: Tom Gindin
> Cc: [e-mail]
> Subject: Re: WG Last Call: AIA CRL extension
> 
> 
> 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
> >
> >
> >