WG Last Call is closed: AIA CRL extension

Tim Polk <tim.polk@nist.gov> Tue, 31 May 2005 23:19 UTC

Message-Id: <5.1.0.14.2.20050531133953.039ad7f0@email.nist.gov>
Date: Tue, 31 May 2005 18:13:42 -0400
To: ietf-pkix@imc.org
From: Tim Polk <tim.polk@nist.gov>
Subject: WG Last Call is closed: AIA CRL extension
Cc: Denis Pinkas <Denis.Pinkas@bull.net>, Stefan Santesson <stefans@microsoft.com>, Russ Housley <housley@vigilsec.com>, kent@bbn.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk


Folks,

The WG has achieved rough consensus on the AIA CRL extension ID.  The 
editors will be submitting a new ID incorporating the changes agreed to on 
list.  When that ID appears, I will forward it to the appropriate Area 
Director for progression.

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: owner-ietf-pkix@mail.imc.org
>>[mailto:owner-ietf-pkix@mail.imc.org]
>>
>>>On Behalf Of Denis Pinkas
>>>Sent: den 25 maj 2005 00:47
>>>To: Russ Housley
>>>Cc: ietf-pkix@imc.org
>>>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:     wpolk@nist.gov
>>>>>>        cc:     housley@vigilsec.com, ietf-pkix@imc.org,
>>>kent@bbn.com,
>>>
>>>>>>stefans@microsoft.com
>>>>>>        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 <tim.polk@nist.gov>
>>>>>>Sent by: owner-ietf-pkix@mail.imc.org
>>>>>>05/10/2005 05:27 PM
>>>>>>
>>>>>>        To:     ietf-pkix@imc.org
>>>>>>        cc:     kent@bbn.com, stefans@microsoft.com,
>>>>>
>>>>>housley@vigilsec.com
>>>>>
>>>>>>        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
>>>>>>
>>>>
>

WG Last Call is closed: AIA CRL extension Tim Polk