Re: WG Last Call: AIA CRL extension

[Denis Pinkas <[e-mail]>]

Stefan and Russ,

> Denis,

> I discussed this with Russ and our conclusion is that if this resolves
> your last call issues, then we can live with deleting these sentences.

If so, my concern is solved.

Thanks,

Denis

PS: Stefan, we do not need to meet anymore next week on this topic,
     and we can spend more time to enjoy some good food on the
     French Riviera.  :-)

> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 25 maj 2005 00:47
>>To: Russ Housley
>>Cc: [e-mail]
>>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:     [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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
> 
>