Subject: Re: 3280bis: CRL validation

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 22 Jun 2005 11:58:01 +0100

David,

(...)

>>> Yet again your message contains nothing but unsupported claims.

>> The "supported claim" is the sentence that I already quoted :

>> "The DN MUST be unique for each subject entity certified by the one CA
>> as defined by the issuer name field".

>What does this prove. According to X.501, Clause 9.2 (Names in General):

>A (directory) name is a construct that identifies a particular object from
>among the set of all objects. A name shall be unambiguous, that is, denotes
>just one object. However, a name need not be unique, that is, be the only
>name that unambiguously denotes the object.

This simply says that, within a directory, a givenname shall not denote two 
different objects, which is obvious.

>So, if the authors of RFC 3280 really meant to use the word "unique", 
>they were simply imposing a restriction that is consistent with, but not 
>required by, X.501.

>If they meant to say "unambiguous" instead of "unique", then they were 
>stating a necessary (but not sufficient) condition for conformance to 
>X.509/X.501.

>> If you have any additional sentence within RFC 3280 that invalidates 
>> that sentence or places an additional constrain, please let us know. 
>> In the absence of such a sentence, ...
>
>There is no need to invalidate a statement this is not incorrect.

 ... but you have not identified an additional constrain.

>> We are here in the PKIW WG and we fix the PKIX text, i.e. RFC 3280 and 
>> similar PKIX documents. There is another forum to fix the ISO text.

>We must remain consistent with X.509. We can specify a path validation 
>algorithm that can tolerate the existence of name collisions, as long as 
>the algorithm does not accept any certification paths that are invalid 
>according to X.509. But, we cannot specify certificate/CRL generation 
>rules that permit the creation of name collisions as that would be 
>inconsistent with X.509 and would result in the generation of 
>certificates and CRLs that could not be safely validated by some X.509 
>compliant path validation implementations.

I understand that you are now "opening a door", since you accept to specify 
a path validation algorithm that can support the existence of name collisions.

Stefan made a very good answer to Sharon objections and I have nothing to add, 
except that Stefan has nicely demonstrated that X.509 is working on the same 
grounds, since there is no global single DIT, but a collection of (independant) DITs.

Denis

>>> You claim that "[i]n RFC 3280, we do use the *syntax* of a DN defined in
>>> X.509, but we always
>>> said that names are only unique for the CA that has assigned them."
>>> Where is your support for the claim that the PKIX WG decided to diverge
>>
>> >from X.509 in such a fundamental way? The entire PKIX mail list archive
>>
>>> seems to be available on-line, so if what you are saying is true, you
>>> should be able to present some evidence.
>>>
>>> Besides, up until now you have been claiming that these rules applied to
>>> X.509, now you are saying that this only applies within PKIX. Which 
>>> is it?
>>>
>>> Denis Pinkas wrote:
>>>
>>>> David,
>>>>
>>>> I could use the same wording as you use:
>>>>
>>>> " You can repeat as many times as you like that DNs need to be 
>>>> globally unique
>>>> but it still won't become true.
>>>>
>>>> Other people (e.g. Santosh, Stefan, Lucien) have pointed this out to 
>>>> you and
>>>> yet you continue to repeat the same false claim. No matter how many 
>>>> times
>>>> you will assert this claim, you will not be able to make it true".
>>>>
>>>> Some please, for the future, keep trying to avoid this kind of wording.
>>>>
>>>> Have said that, let us come to the core of the issue.
>>>>
>>>> When we started this WG (and I was in the meeting room), we said that
>>>> we take X.509, but we do not take X.500. In PKIX, we do not need X.500,
>>>> so that X.509 can work.
>>>>
>>>> We do not consider that a unique DIT exists in RFC 3280. Make a search
>>>> for "DIT" and you will find thes three letters nowhere.
>>>>
>>>> As Stefan pointed out, there are many different DITs, in teh contxt of
>>>> RFC 3280 as many as there are CAs in the world.
>>>>
>>>> In RFC 3280, we do use the *syntax* of a DN defined in X.509, but we 
>>>> always
>>>> said that names are only unique for the CA that has assigned them.
>>>>
>>>> "The DN MUST be unique for each subject entity certified by the one CA
>>>> as defined by the issuer name field".
>>>>
>>>> There is no other constrain in RFC 3280.
>>>>
>>>> I would believe that some people originally thought that the only way
>>>> to make RFC 3280 secure was to have globally unique names, which is not
>>>> a practical case and mentioned nowhere in RFC 3280.
>>>>
>>>> The good news is that it is indeed possible to have security without 
>>>> making
>>>> the (false) assumption that names issued by CAs are globally unique.
>>>>
>>>> The bad news may be that some people built their systems making that 
>>>> (false)
>>>> assumption and thus implementations that would be built on that 
>>>> assumption
>>>> would be vulnerable to some attacks.
>>>>
>>>> Denis
>>>>
>>>>
>>>>
>>>>>> David,
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Stefan Santesson wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Show me the paragraph in X.509 or RFC 3280 that says that the 
>>>>>>>> subject of
>>>>>>>> a compliant certificate MUST have a name that corresponds to a 
>>>>>>>> globally
>>>>>>>> unique entry in the DIT.
>>>>>>>>
>>>>>>>>
>>>>>>> I really don't want to get involved in a discussion about whether 
>>>>>>> it was
>>>>>>> a wise or unwise decision for X.509 to be designed around the 
>>>>>>> assumption
>>>>>>> that name collisions will not occur, but here are some quotes 
>>>>>>> from X.509
>>>>>>> and X.501:
>>>>>>>
>>>>>>>
>>>>>>> X.509, Clause 3.2 (Directory model definitions): The following 
>>>>>>> terms are
>>>>>>> defined in ITU-T Rec. X.501 | ISO/IEC 9594-2: f) distinguished name;
>>>>>>>
>>>>>>>
>>>>>>> X.509, Section 7 (Public-keys and public-key certificates): NOTE 1 –
>>>>>>> Although the CAs are unambiguously defined by a distinguished name in
>>>>>>> the DIT, this does not imply that there is any relationship 
>>>>>>> between the
>>>>>>> organization of the CAs and the DIT.
>>>>>>>
>>>>>>>
>>>>>> In X.500 there is a single "DIT", whereas in X.509 there is a DIT 
>>>>>> per CA.
>>>>>> Full stop.
>>>>>>
>>>>>>
>>>>> Denis,
>>>>>
>>>>> You can repeat this as many times as you like and it still won't 
>>>>> become
>>>>> true. You keep insisting that X.509 follows a different model than
>>>>> X.500. But,
>>>>>
>>>>> (1) X.509 states that it uses the naming model from X.501 and
>>>>> specifically states that names are unambiguous (nowhere does it say
>>>>> unambiguous relative to ....)
>>>>>
>>>>> (2) X.501 (in clause 1, Scope) states that the concepts defined in 
>>>>> that
>>>>> document are used in the other documents in the X.500 series, 
>>>>> including
>>>>> X.509.
>>>>>
>>>>> (3) The people who wrote these documents insist that they really meant
>>>>> that names in X.509 are unambiguous, and are not simply unambiguous
>>>>> relative to the issuing CA.
>>>>>
>>>>>
>>>>> People have pointed this out to you over and over again in multiple
>>>>> forums and yet you continue to repeat the same false claim. No matter
>>>>> how many times you have asserted this claim, you have never be able to
>>>>> point to text in the standards to support your claim.
>>>>>
>>>>> In X.509, not Denis' mind, names are unambiguous.
>>>>>
>>>>> You can argue as much as you want about how X.509 SHOULD HAVE been 
>>>>> based
>>>>> on locally distinct names, but there is a difference between "should
>>>>> have" and "did".
>>>>>
>>>>> If you are going to continue to claim that X.509 WAS written around 
>>>>> the
>>>>> assumption that naming is local, then please explain:
>>>>>
>>>>> (1) Why the text states that names are unambiguous without indicating
>>>>> that names are only unambiguous within a certain scope.
>>>>>
>>>>> (2) Why all of these rules that you have noted would need to be 
>>>>> enforced
>>>>> in order to ensure security in an environment in which names are only
>>>>> distinct with respect to the issuing CA were not included in the 
>>>>> standard.
>>>>>
>>>>> (3) Why the people who actually developed and wrote the standard claim
>>>>> that X.509 was written based on the assumption that names are globally
>>>>> unambiguous (just as the standard states).
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>>>
>>>> Regards,
>>>>
>>>> Denis Pinkas
>>>>
>>>>
>>>>
>>
>> Regards,
>>
>> Denis Pinkas
>>
>

Regards,

Denis Pinkas

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 22 Jun 2005 08:56:05 -0400

Denis,

You have still not answered any of my questions. You still continue to 
make nothing but unsubstantiated claims.

You have only identified one sentence that you claim supports your 
argument, but this sentence states that a CA may not issue two 
certificates with different subject DNs to a single entity. This in no 
way supports your argument.

As to my "opening a door", I have always said this. While I believe that 
the problem of name collisions between CAs to be more of a theoretical 
concern than a practical concern, it can be addressed if that is working 
group consensus. The PKIX Certificate and CRL profile is a profile of 
X.509. It can be more restrictive in both its generation and validation 
requirements as long as it is consistent. We should be very careful, 
however, about mandating the use of a more restrictive path validation 
algorithm. In RFC 3280, the CRL validation algorithm is designed so that 
it will accept any valid CRL issued in conformance with RFC 3280, but 
the algorithm will not accept all valid CRLs issued in conformance with 
X.509. This was done in order to simplify the algorithm. We do not, 
however, forbid the use of a more complicated CRL validation algorithm 
that would accept all valid CRLs.

As I have said before, I am in favor of introducing path validation 
algorithms that only consider CRL certification paths that closely 
correspond to the certification paths for the certificate being 
validated. But, the reason that I am interested in this is that I 
believe such algorithms would improve the efficiency of path discovery 
without significantly impacting functionality. If it also happens to 
provide an extra layer of security in case of name collisions that's 
even better. But, I think this should be left as advice rather than as a 
mandate.

Dave