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

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

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