RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

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

Santosh,

Agree, I was talking about 3280bis.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 25 maj 2005 11:23
> To: [e-mail]
> Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
> Stephan,
> 
> Validation related text (e.g., infinite loops) belongs more in 3280.
> Having
> it in the new I-D does not harm.  But, validation should be addressed
by
> 3280 and not diced up in multiple RFC and then served.
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Wednesday, May 25, 2005 2:18 PM
> To: Tom Gindin; Santosh Chokhani
> Cc: [e-mail]; Julien Stern
> Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
> Tom,
> 
> If the substitution would be successful the validation would go into
an
> infinite loop and fail. Validation of S's fake CRL requires validation
of
> C's cross certificate to S which triggers another validation of S's
fake
> CRL
> and so on.
> 
> I think we added some text against infinite loops but I don't have it
> fresh
> in my memory.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Tom Gindin
> > Sent: den 25 maj 2005 04:50
> > To: Santosh Chokhani
> > Cc: [e-mail]; 'Julien Stern'
> > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> >
> >
> >         Santosh:
> >
> >         A relatively concrete example would be the following:
> >         Assume a trust anchor called A, and CA it has issued a cross
> > certificate to called C.  Further assume that C uses indirect CRL's,
> and
> > has issued a cross certificate without name constraints to another
CA
> > called S. Then assume that S goes rogue and creates a CRL signing
> > certificate with the same name as C uses for its indirect CRL's (the
> key
> > pair in that certificate is hereinafter called the "rogue CRL
> signer").
> > Further assume that C finds out about this and creates a CRL listing
S
> as
> > revoked, but that S successfully replaces that CRL in the repository
> by
> > one signed by the rogue CRL signer.
> >         Does RFC 3280 path validation consider S invalid?  If so,
> which
> > step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is
there
> > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what
> else
> > would be likely to cause S to be recognized as invalid?  You could
> > probably patch any difficulties by adding "if the certificate whose
> > revocation is being checked appears in the path, reject it" to
> 6.3.3-f.
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> >
> > "Santosh Chokhani" <[e-mail]>
> > 05/24/2005 06:42 PM
> >
> >         To:     Tom Gindin/Watson/IBM@IBMUS, <[e-mail]>
> >         cc:     "'Julien Stern'" <[e-mail]>
> >         Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL
> > extension)
> >
> >
> > Tom,
> >
> >
> > I assume you are talking about CRL certification path solution I
> proposed
> > will not permit the scenario?  I still do not see in your case, if
the
> > Subject CA (cross certified CA) is revoked, you will verify the path
> to it
> > in the first place.  May be I am not understanding your scenario
> properly.
> > How does the revoked CA gets verified?
> >
> >
> > Julien,
> >
> > We have defined and proven the solution for how to do this.  The
> scenario
> > you proposed is not something X.509 worries about (A CA that is
still
> > valid, but has gone bad).
> >
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On
> > Behalf Of Julien Stern
> > Sent: Tuesday, May 24, 2005 3:49 PM
> > To: Stefan Santesson
> > Cc: Tom Gindin; [e-mail]
> > Subject: Re: WG Last Call: AIA CRL extension
> >
> >
> >
> > 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
> > > > >
> > > > >
> > > > >
> > >
> >
> >
> 
>