Re: WG Last Call: AIA CRL extension

[Tim Polk <[e-mail]>]

Folks,

My reading of this thread says that rough consensus has been achieved on 
the AIA CRL extension ID, and that I can forward the document to the 
appropriate Area Director after deletion of these sentences.  (If anyone 
disagrees, please say so on list ASAP!)

As noted, this issue will have to be addressed in the context of 
3280bis.  It is clear that the current content of 3280bis with respect to 
CRL validation does not enjoy consensus within the working group.

Thanks,

Tim Polk

At 04:36 PM 5/25/2005 +0200, Denis Pinkas wrote:

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