Re: WG Last Call: AIA CRL extension

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

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> 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. 

Stefan,

I agree with you. Actually, I would tend to believe that a _real_
discussion would have to take place at some point regarding the overall
security model of CRL validation, but I have absolutely no objection to
the AIA, as soon as it is made clear that it's only goal is to simplify
path building implementations, and not to adress security issues. My
very humble take on the subject is that Denis and yourself have been
arguing on the list on absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not
any more) about AIA, but I still think that a discusssion regarding
revocation validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

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