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

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

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