Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

["Denis Pinkas" <[e-mail]>]

>Denis,
>
>As you might have seen from some of my old posting on the list,
>I initially believed that there was a true "security flaw" in X.509
>regarding revocation.
>
>Now, my understanding is that the fact there is no name
>collision is an _assumption_ in X.509.

No name collision is simply an invalid assumption.

>If one wants to cope with name collisions there are several
>routes one can take depending on what the "adversary" is and
>the constraint one wants to put on the PKI topology.
>
>1) The first one is simply to assume that it can be detected
>and fixed.

It can't.

>2) One can cope with "accidental" name collision: I believe that is
>the route currently taken by PKIX by mandating trust anchor matching.

Same trust anchor is insufiicient.

>3) Your proposed wording copes with less accidental and more malicious
>attacks. 

It addresses the general case.

> I believe this is in the same spirit as Santosh Chokani
>proposal in 2004, (isn't it ?). 

No. Santosh was certainly mandating the same trust anchor, but this is not sufficient.
But I let Santosh explains. 

> However, it restricts the PKI topology and

It does not.

>I believe it is still open to some exotic attacts (see my posting from
>early November 2004).

I do not recall that you have explained an attack on that scheme.

>4) One can put even more restrictions on the PKI topology by mandating
>that a CA signs the CRL issuer keys with an explicit "CRL issuer" extension
>(similar to OCSP) and that the AuthorityKeyExtension (containing the
>hash of the key) be explicitely checked during the path building.

The AuthorityKeyExtension is not done for this.

>All in all, I believe it is close to impossible to define a general rule
>in the standard because some core assumptions regarding the uniqueness
>of the DNs and the adversarial model may not be the same between
>different PKIs.

It is possible to define a default rule.

Remember:

A DN issued by one CA is unique for that CA, but for that CA only.
Only a chain of DNs may be unique, starting from a trust anchor.

which means, as Russ noticed, that it is not allowed to have two different roots 
in a validation policy (or a signature policy) with the same DN.

Denis

>Regards,
>
>--
>Julien
>
>On Mon, Oct 22, 2007 at 03:16:32PM +0200, Denis Pinkas wrote:
>> 
>> Julien,
>> 
>> >On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote:
>> >>
>> >> [snip]
>> >
>> >Hi Denis,
>> >
>> >> This means that RFC3280bis currently provides no coorect guidance 
>> >> on how implementers should address this issue. 
>> >
>> >Agreed. There is a somewhat "matter of local policy-ish" issue here.
>> >
>> >> The following text is an attempt to address this issue:
>> >> 
>> >> "Implementations validating indirect CRLs MUST make sure that the 
>> >> certificate of the CRL Issuer is indeed issued by the CA that issued 
>> >> the certificate to be verified, which means that the sequence of DNs 
>> >> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
>> >> must be identical to the the sequence of DNs of the certification path 
>> >> of the certificate to be verified, up to the DN of the same trust anchor".
>> >
>> >Forcing the CA to directly issue the CRL issuer certificate is way too
>> >restrictive in my humble opinion. I have an example of a PKI where there
>> >is a single (indirect) CRL issuer for about 20 CAs.
>> >
>> >The CRL issuer certificate is issued by the (Root) CA that issued
>> >those 20 CA certificates.
>> 
>> What about:
>> 
>> Unless a local policy states otherwise, implementations validating indirect CRLs 
>> MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA 
>> that issued  the certificate to be verified, which means that the sequence of DNs 
>> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
>> must be identical to the the sequence of DNs of the certification path 
>> of the certificate to be verified, up to the DN of the same trust anchor".
>> 
>> Denis
>> 
>> >Regards,
>> >
>> >--
>> >Julien
>> >
>> >> Denis
>> >> 
>> >> >Russ
>> >> >
>> >> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>> >> >
>> >> >>Title: Liaison to IETF on the resolution of DR320
>> >> >>Submission Date: 2007-10-05
>> >> >>URL of the IETF Web page: 
>> >> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>> >> >>Please reply by 2008-03-01
>> >> >>
>> >> >>From: Xiaoya Yang(ITU-T SG 17) <[e-mail]>
>> >> >>To: IETF/PKIX(Russ Housley <[e-mail]>, Stefan Santesson 
>> >> >><[e-mail]>)
>> >> >>Cc: Herbert Bertine <[e-mail]>
>> >> >><[e-mail]>
>> >> >><[e-mail]>
>> >> >><[e-mail]>
>> >> >>Reponse Contact: Xiaoya YANG <[e-mail]>
>> >> >><[e-mail]>
>> >> >>Technical Contact: <[e-mail]>
>> >> >><[e-mail]>
>> >> >>Purpose: For action
>> >> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>> >> >>rejected Defect Report 320 
>> >> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>> >> >>AFNOR.  This DR advanced an argument that Distinguished Names may 
>> >> >>not be unique and as such, the DN of the Certificate User may not be unique.
>> >> >>The directory group believes that Distinguished Name values must be 
>> >> >>unique and unambiguously identify a single entity, hence the use of 
>> >> >>the term Distinguished.
>> >> >>The DR states “the DN of the issuer name cannot be guaranteed to 
>> >> >>be unique”.  X.509 takes its definition of DN from X.501.  Clause 
>> >> >>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>> >> >>clause states A name shall be unambiguous, that is, denotes just one object.
>> >> >>Clause 9 goes on to state: It is the responsibility of the relevant 
>> >> >>naming authority for an entry to ensure that this is so by 
>> >> >>appropriately assigning distinguished attribute values.  Allocation 
>> >> >>of RDNs is considered an administrative undertaking that may or may 
>> >> >>not require some negotiation between involved organizations or 
>> >> >>administrations.  This Directory Specification does not provide such 
>> >> >>a negotiation mechanism, and makes no assumption as to how it is performed.
>> >> >>The standard takes an axiomatic view of the concept that a 
>> >> >>distinguished name unambiguously identifies a single entity.  Things 
>> >> >>break if two entities identify themselves using the same name.  We 
>> >> >>don't let two entities have the same domain name or the same email 
>> >> >>address.  Why? - because things wouldn't work.
>> >> >>The directory group does not accept the DR’s basic argument.  We 
>> >> >>believe that if two entities present the same name and a CA issues a 
>> >> >>certificate to each, that CA made a mistake - not a naming authority 
>> >> >>mistake, since a CA is not an naming authority (although one entity 
>> >> >>can be both), but an entity to key binding mistake that leads to 
>> >> >>confusion and even worse, a security risk.
>> >> >>We believe that if two entities claim the same name as top level 
>> >> >>CAs, there is a political/procedural breakdown much like the domain 
>> >> >>ownership arguments we have seen.  No one argues that the Internet 
>> >> >>protocols should be modified to solve that problem.  The conflict is 
>> >> >>resolved and one entity is assigned the name.  The group believes 
>> >> >>that this is the only reasonable solution for Distinguished 
>> >> >>Naming.  One votes for the CA of choice by configuring it as an anchor.
>> >> >>One of the participants in the directory meeting stated that 
>> >> >>Certification Authorities are being deployed with names not acquired 
>> >> >>from naming authorities but with names arbitrarily chosen assuming 
>> >> >>that no other CA is or will be operating under that name.  That 
>> >> >>participant further stated that the IETF provides no guidelines on 
>> >> >>ensuring that the names of CAs are unambiguous.
>> >> >>The directory group requests the IETF PKIX group to comment on this 
>> >> >>statement.  If the statement is correct, we ask the IETF to consider 
>> >> >>putting a mechanism in place to prevent conflict, e.g. a list of 
>> >> >>existing CA names that deployers of new CAs could check for naming conflicts.
>> >> >>Attachment(s):
>> >> >>No document has been attached
>> 
>> 
>

Regards,

Denis Pinkas