[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG Last Call: AIA CRL extension



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: owner-ietf-pkix@xxxxxxxxxxxx

[mailto:owner-ietf-pkix@xxxxxxxxxxxx]


On Behalf Of Denis Pinkas
Sent: den 25 maj 2005 00:47
To: Russ Housley
Cc: ietf-pkix@xxxxxxx
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@xxxxxxxx
       cc:     housley@xxxxxxxxxxxx, ietf-pkix@xxxxxxx,

kent@xxxxxxx,


stefans@xxxxxxxxxxxxx
       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@xxxxxxxx>
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
05/10/2005 05:27 PM

       To:     ietf-pkix@xxxxxxx
       cc:     kent@xxxxxxx, stefans@xxxxxxxxxxxxx,


housley@xxxxxxxxxxxx


       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