[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
>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) <tsbsg17@xxxxxxx>
>> >> >>To: IETF/PKIX(Russ Housley <housley@xxxxxxxxxxxx>, Stefan Santesson
>> >> >><stefans@xxxxxxxxxxxxx>)
>> >> >>Cc: Herbert Bertine <hbertine@xxxxxxxxxxxxxxxxxx>
>> >> >><tsbsg17@xxxxxxx>
>> >> >><era@xxxxxxxxxx>
>> >> >><hoytkesterson@xxxxxxxxxxxxx>
>> >> >>Reponse Contact: Xiaoya YANG <xiaoya.yang@xxxxxxx>
>> >> >><tsbsg17@xxxxxxx>
>> >> >>Technical Contact: <era@xxxxxxxxxx>
>> >> >><hoytkesterson@xxxxxxxxxxxxx>
>> >> >>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