Subject: Re: 3280bis: CRL validation

From: Denis Pinkas <[email-masked]>
Date: Fri, 03 Jun 2005 17:19:24 +0200

David,

> Denis,
> 
> You have been saying for some time that "CRL validation is NOT specified 
> in RFC 3280".  But, the more you post about CRL validation, the more 
> clear it becomes that the problem is that you do not understand how CRL 
> validation works in X.509.  Further, it is not clear that the problem is 
> with the text of X.509 or RFC 3280 or if it is just that X.509 does not 
> work the way you believe (or want) it to work.

The more you post about CRL validation, the more clear it becomes that the 
problem is that you do not understand the difference between X.500 and X.509.

> X.509 was designed based on a model in which names are globally unique.  

No. X.500 was designed based on a model in which names are globally unique.

> In November on the X.500 mail list, you tried to argue otherwise, but it 
> was demonstrated quite convincingly that this is what X.509 says:
> 
>    X.509, clause 8.3.2.1 (subject alternative name extension):
> 
>        The values in the alternatives of the GeneralName type are names 
> of various forms as follows:
> 
>               directoryName is a directory name defined in accordance 
> with ITU-T Rec. X.501 | ISO/IEC 9594-2;

There is a difference between a Directory name, with a capital D and a 
directory name. The Directory (i.e. X.500) failed, but the good part of it, 
i.e. X.509, remains.

> (NOTE that directoryName is of type Name, which is the also the type 
> used to define the issuer and subject fields)
> 
>    X.501, clause 9.1 (Definitions):
> 
>      9.1.4 (directory) name: A construct that singles out a particular 
> object from all other objects.
>      A name shall be unambiguous (that is, denote just one object), 
> however it need not be unique
>      (that is, be the only name which unambiguously denotes the object).

A name is unambiguous for a given directory, but two directories (from 
different organisations) may contain the same name that denotes a different 
object.

>    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. A 
> (directory) name also identifies
>      an entry. This entry is either an object entry that represents the 
> object or an alias entry which
>      contains information that helps the Directory to locate the entry 
> that represents the object.
> 
>      An object can be assigned a distinguished name without being 
> represented by an entry in the
>      Directory, but this name is then the name its object entry would 
> have had were it represented
>      in the Directory.
> 
>      Syntactically, each name for an object or entry is an ordered 
> sequence of relative distinguished
>      names (see 9.3).
> 
>      Name ::= CHOICE { -- only one possibility for now -- rdnSequence 
> RDNSequence }
> 
>      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
> 
>      DistinguishedName ::= RDNSequence
> 
> Note that I am not try to argue that it is impossible for two entities 
> within a PKI to be assigned the same name, just that this would be 
> inconsistent with the model upon which X.509 was developed.

With the X.509 model it is possible for two entities to be assigned the same 
name.

The assumption you are making does not stand and X.509 is not based on that 
assumption. It does not NEED to be based on that assumption to be secure.

> In a message to the PKIX list on April 11 about the CRL AIA draft, you 
> wrote:
> 
>> In order to build a path, a relying party needs to make sure of the 
>> name of the CRL Issuer, which means not simply knowing the DN of the 
>> CRL issuer but also all the other DNs from the upper CAs up to a root 
>> key.
> 
> 
> As noted above, in X.509 an object is uniquely identified by its DN.

As noted above, this is wrong.

> There is no notion of forming that "name" of an object by creating a 
> sequence of DNs.  In the context of your comment above, you seem to be 
> suggesting that the "name" of the CRL Issuer consists of the sequence of 
> names from the certificates forming a certification path that starts at 
> a "root" and ends with the CRL Issuer.  But, this does not make sense 
> for two reasons.  First, in the X.500 series, naming is defined in 
> X.501.  That is, the concept of PKI is not used in defining naming.  
> Second, a naming scheme like this could only work if PKIs were limited 
> to being hierarchies, which they are not.

A name is only relevant if you know whihc CA has issued that name and which 
other CA has issued the namlme of that CA, and so on up to a trust anchor.

It does not necessarily means that the name is a construct of DNs, but that 
you can make sure where to relate a given name in a certification tree.

> In the same message on April 11, you wrote:
> 
>> Let us consider two different scenarios where this new extension [AIA 
>> extension in a CRL] would be considered.
>>
>> Scenario A: The relying party does not trust any CRL issuer in 
>> particular and will simply use the CRL Issuer designated by the 
>> Certificate Issuer by means of the CRL DP extension.
>>
>> Scenario B: The relying party trusts at least a specific CRL issuer 
>> and will get the CRLs from that CRL Issuer and then will make sure 
>> that the information contained in them matches with the designation of 
>> the Certificate Issuer.
> 
> 
> X.509/RFC 3280 does not allow for scenario B.  With OCSP a relying party 
> may choose to accept status information from a locally trusted OCSP 
> server.  

So yo say that we have an asymmetrical model, i.e. with OCSP it is possible 
to rely on a single OCSP responder while for CRLs it is not possible to rely 
on a single CRL responder. If we take away case B, then this simplifies the 
issue a little bit.

> With CRLs, a CRL may only be used to verify the status of a 
> certificate if the certificate explicitly indicates that CRLs from that 
> issuer may be used.  This can be done in two ways.  Either (1) the 
> certificate issuer and CRL issuer are the same entity (i.e., the issuer 
> fields in the certificate and CRL contain the same name) or (2) the 
> certificate includes a cRLDistributionPoints extension in which the 
> cRLIssuer field is present and contains the name of the CRL issuer.  
> This is covered in RFC 3280 in section 6.3.3, step (b)(1):
> 
>    6.3.3  CRL Processing
> 
>       (b)  Verify the issuer and scope of the complete CRL as follows:
> 
>             (1)  If the DP includes cRLIssuer, then verify that the issuer
>             field in the complete CRL matches cRLIssuer in the DP and that
>             the complete CRL contains an issuing distribution point
>             extension with the indrectCRL boolean asserted.  Otherwise,
>             verify that the CRL issuer matches the certificate issuer.

The text says "the issuer field in the complete CRL matches cRLIssuer in the 
DP" but this is insufficient to handle name collisions.

> As to your specific comments below:

> For issue 33, you are misinterpreting the certificateIssuer extension.  
> The certificateIssuer extension is defined as GeneralNames so that one 
> can include more than one name for the certificate issuer (e.g., the 
> name from the issuer field of the certificate and one or more names from 
> the issuerAltName extension of the certificate).  That is it is a 
> sequence (or logically a set) of names for a single entity.  It is not 
> intended to specify a certification path.

No text said otherwise. The text is left open to (too many) interpretations 
and so we will need to fix it.

> As for issue 43, as I argued above, whether you like it or not, X.509 
> was designed based on the assumption that name collisions will not 
> occur.  

Whether you like it or not, X.509 is not designed based on the assumption 
that name collisions will not occur.

> (Of course a "rogue" CA could issue such certificates, but X.509 
> assumes that rogue CAs are untrusted (either they are never issued a 
> certificate or certificates issued to them are revoked) so that any name 
> collisions they create will not affect the security of the PKI).  Again, 
> you may believe that it was a bad idea to make such an assumption, but 
> this doesn't change the fact that this assumption was used in the design 
> of X.509.

This doesn't change the fact that this assumption does not need to be used 
(and was NOT used) in the design of X.509.

> Recently, a number of people on the PKIX list, including you, have 
> argued that it is unsafe to assume that no two authorities (e.g., CA 
> and/or CRL issuer) will issue certificates and/or CRLs under the same 
> name.  In particular, they are concerned that at some point there will 
> be two trusted authorities that belong to the same PKI that are issuing 
> certificates and CRLs under the same name, that no one will detect this, 
> and that this may result in a relying party using a CRL issued by one of 
> the authorities to validate a certificate issued by the other 
> authority.  Since the CRL does not actually cover the certificate, it 
> will not provide accurate information about the status of the certificate.

Correct.

> At the IETF meeting in November, Santosh presented a proposal for a 
> restricted version of the certification path validation algorithm that 
> would prevent a relying party from using a CRL issued by the wrong 
> authority to validate the status of a certificate, even if name 
> collisions occurred, so long as no trusted CA issued two certificates to 
> different entities with the same subject DN.

The proposal from Santosh has nothing to do with my proposal and I do NOT 
support his proposal.

> At the meeting, the concern was expressed that incorporating this new 
> algorithm into 3280bis would be too big of a change from RFC 3280 and so 
> trying to incorporate it into 3280bis would unacceptably delay the 
> completion of 3280bis.  So, it was suggested that Santosh's proposal 
> should be advanced in a separate document.  At the same time, several 
> people felt that if name collisions between authorities were ever going 
> to be seen, it would be as a result of two authorities in two different 
> PKIs using the same name, but with both authorities being trusted by a 
> relying party as a result of the relying party using multiple trust 
> anchors.  

The wording "same PKI" or different PKIs" is meaningless. Under a validation 
policy there may be one or more trust anchors with a certification tree 
below. Nothing prevents two entities to be given the same DN by any two 
different CAs: these CAs do not know each other.

 > Indicating that the certification path for a certificate and
> the corresponding CRL should start at the same trust anchor would 
> prevent the use of the wrong CRL in this case. 

Certainly not. The correct sentence is:

    "Indicating that the certification path for an entity certificate and
    the CRL issuer certificate shall *end* at the same CA will prevent
    the use of the wrong CRL in this case".

> So, the initial 
> agreement that came out of the November IETF meeting was to include a 
> note in the security requirements section of 3280bis about the use of a 
> common trust anchor in order to mitigate the risk that might result if a 
> name collision ever did occur and to leave any further work on this 
> issue to another document.

See above.

> Note that I am personally in favor of Santosh's proposal, 

Note that I am personally against Santosh's proposal which is over-complex.

> mainly because 
> I believe that imposing such restrictions on the certification path for 
> the CRL will limit the search space for the certification path and will 
> thus lead to more efficient implementations.  While I am not 
> particularly concerned about the name collision risk, 

You should, because nothing will PREVENT it, whatever assumptions you are 
making.

Denis

 > I do not think
> that the restrictions that Santosh's algorithm imposes pose any problems 
> either.  However, PKIX standards, including 3280bis, are developed by 
> consensus; I cannot simply write my own personal views into the standard.
> 
> Dave
> 
> Denis Pinkas wrote:
> 
>> To the list,
>>
>> I changed the name of the thread which is now under 3280bis.
>>
>> As Tim mentioned: "it is clear that the current content of 3280bis 
>> with respect to CRL validation does not enjoy consensus within the 
>> working group".
>>
>> Issues 33 and 43 are directly related to this topic. They are both 
>> copied below:
>>
>> 33) The certificateIssuer CRL entry extension contains a GeneralNames. 
>> While RFC 3280 does not state this, there seems to be general 
>> agreement that the certificateIssuer extension should only contain the 
>> DN from the issuer field of the certificate being revoked.
>>
>>   3280bis states: "Conforming CRL issuers MUST include in [the
>>   certificateIssuer] extension the distinguished name (DN) from the
>>   issuer field of the certificate that corresponds to this CRL entry.
>>   The encoding of the DN MUST be identical to the encoding used in the
>>   certificate."
>>
>>
>>  43) It should be noted in 3280bis that there is a risk that two 
>> different
>>      CAs (or a CA and a CRL issuer) may issue certificates and CRLs under
>>      the same name and that if this happens there is a risk that a 
>> relying
>>      party will validate a certificate issued by one of these entities
>>      using a CRL issued by the other.
>>
>>   The security considerations section of 3280bis states that CAs and CRL
>>   issuers should be formed in a way that reduces the likelihood of name
>>   collisions.  It also states that 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.
>>
>> Both statements are incorrect.
>>
>> For issue 43: name collisions are possible and a design cannot be 
>> based on the assumption that name collisions, whether accidental or 
>> intentional, will never happen. This means that chosing names to 
>> "reduce the likehood of name collisions" is not a way to solve the 
>> issue. Termination at the same trust anchor without additional details 
>> does not solve the issue either.
>>
>> For issue 33: the certificateIssuer extension is defined as :
>>
>>      certificateIssuer ::= GeneralNames
>>
>> with
>>
>>      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>>
>> It is not defined as:
>>
>>      certificateIssuer ::= GeneralName
>>
>> ... and this is NOT an error.
>>
>> To go directly to the point, certificateIssuer may contain in practice 
>> either:
>>
>>  - one name, or
>>  - a sequence of names.
>>
>> If it contains one name, this means that this name MUST be certified 
>> by the CA that has issued the certificate where the extension appears.
>>
>> If it contains a sequence of names, this means that the certification 
>> path of the CRL issuer certificate formed using that sequence of names 
>> MUST also terminate at the trust anchor of the target certificate.
>>
>> This is secure and avoids any name collision, either deliberate or 
>> intentional.
>>
>> Denis
> 
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 04 Jun 2005 03:55:57 +1200

Denis Pinkas <[email-masked]> writes:

>The Directory (i.e. X.500) failed, but the good part of it, i.e. X.509,
>remains.

"good"?  Hmm [flips through dictionary]... oh I see, you're using "good" here
to mean "ample, substantial", as in "The PKIX profile of X.509 covers a _good_
part of 2,000 pages of text".  Well, there can be no doubt that X.509 has
become gooder than X.500 ever was, and is only going to become gooder in the
future.

Peter.

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 14 Jun 2005 11:52:58 +0100

Steve,

I agree with your conclusion.
We must assume legitimate DN reuse in our model, not only for end
entities but also for CAs.

In many cases CA's will attest that a name is correct, but not
necessarily that it is unique.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 3 juni 2005 19:53
> To: Sharon Boeyen
> Cc: 'Denis Pinkas'; David A. Cooper; pkix
> Subject: RE: 3280bis: CRL validation
> 
> 
> Sharon,
> 
> I agree that the X.500 model of naming assumes unambiguous names and
> that X.509, inherits this model. However, in reality,  we do not have
> a global DIT and thus there are no good assurances that CAs operating
> in different contexts will not issue certs to different entities
> using the same subject DN. As a result, I think we have to develop
> standards guidance that acknowledges the potential of DN reuse under
> different CAs.
> 
> Steve

---

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 16 Jun 2005 11:01:42 +0100

David,

>When you say that the concept of indirect CRL covers two very distinct 
>cases, are you referring to these two cases?

>>There are two cases to consider for CRL issuers.

>>  a) the CRL Issuer issues revocation information for a single CA;
>>  b) the CRL Issuer issues revocation information for more than one CA.

>>Case a) is simple, while case b) is more much complex (this is the "zillions of cases").

>The concept of indirect CRLs is very simple: If the scope of the CRL 
>includes certificates that have an issuer name (i.e., the contents of 
>the issuer field in the certificate) that is different that the issuer 
>name of the CRL (i.e., the contents of the issuer field in the CRL), 
>then it is an indirect CRL. 

I am very sorry, but what you say is in contradiction with 3280bis (see page 51):

   "Whenever the CRL issuer is not the CA that issued the
   certificates, the CRL is referred to as an indirect CRL."

> If the scope of the CRL only includes 
>certificates that have the same issuer name as the CRL, then it is not 
>an indirect CRL. In what way is the concept of indirect CRLs vague?

See above.

There exists three cases:

1) The CA is also issuing the CRL (i.e. it uses the same key to both 
    create certificates and sign CRLs).

2) The CA is delegating responsibility to one CRL Issuer and that CRL Issuer 
   is only taking care of revocation status information for certificates issued by that CA.

3) The CA is delegating responsibility to one CRL Issuer and that CRL Issuer 
   is taking care of  revocation status information for certificates issued different CAs.

From the definition on page 51 (unless we change it) cases 2 and 3 are "indirect CRLs". 
This is was I was referring to as cases a) and b) in my earlier e-mails.

>The scope of an indirect CRL may include certificates issued by one or 
>more CAs, but the mechanisms work the same way no matter how many 
>different CA's certificates are included in the scope of the CRL.

So you are taking of case 3, whereas I say let us first agree on cases 1 and 2, 
where case 2 is also called in my earlier e-mails case b).

Once, an only once, the two first cases will be solved and agreed, 
then we may start the discussion on case 3 which has many security issues 
which may only be solved by making different local additional security assumptions.

So I keep the very useful text you provided below for future discussions. 

Denis

>If you have a certificate and a CRL with different issuers (i.e., 
>different DNs in the issuer fields), the following must be verified to 
>determine if the scope of the CRL includes the certificate:
>
>(1) The certificate must include a cRLDistributionPoints extension with 
>a distribution point that has the cRLIssuer field present and include 
>the DN from the issuer field of the certificate.
>
>(2) The CRL must include an issuingDistributionPoint field with 
>indirectCRL set to TRUE.
>
>(3) If the issuingDistributionPoint field in the CRL includes a 
>distributionPoint name, the cRLDistributionPoints extension in the 
>certificate must include a matching distributionPoint name (as specified 
>in section 6.3.3, step (b)(2)(i)).
>
>(4) The onlyContainsUserCerts, onlyContainsCACerts, and 
>onlyContainsAttributeCerts flags in the issuingDistributionPoint 
>extension in the CRL must all be false or the flag that is set to true 
>must be appropriate for the type of certificate.
>
>If the certificate is covered by the CRL, then one can scan the revoked 
>certificates list to see if the certificate is revoked for one of the 
>reasons covered by the CRL using the certificateIssuer CRL entry 
>extension to determine the issuer name associated with each serial 
>number listed (if the entry includes a certificateIssuer CRL entry 
>extension, the use that issuer name; if the entry does not include a 
>certificateIssuer CRL entry extension, use the issuer name from the most 
>recent preceding entry to include this extension; if the entry does not 
>include a certificateIssuer CRL entry extension and no preceding entry 
>included this extension, then the issuer name is the value from the 
>issuer field in the CRL).
>
>You keep insisting that there are "zillions of cases" that need to be 
>addressed. How does the fact that an indirect CRL happens to cover 
>certificates issued by more than one CA complicate matters. Note that 
>there is no need to consider the possibility that an indirect CRL will 
>cover certificates issued by two different CAs that issue certificates 
>under the same name:
>
>X.509, Clause 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.
>
>X.509, Clause 8.3.2.1 (Subject alternative name extension): For every name
>form used in the GeneralName type, there shall be a name registration system
>that ensures that any name used unambiguously identifies one entity to both
>certificate issuer and certificate users.
>
>
>Dave
>
>
>Denis Pinkas wrote:
>
>> Santosh,
>>
>>> Denis,
>>
>>> The situation I am discussing is when the CRL Issuer is also the 
>>> certificate
>>> issuer.
>>
>> Who need to solve these kinds of issues one by one.
>>
>>> As to the indirect CRL, there are no constraints in the standard that the
>>> indirect issuer needs to be issued a certificate by the CA and the 
>>> indirect
>>> CRL issuer cover only one CA.
>>
>> The concept of "indirect CRL" is currently too broad (and too vague) 
>> since it covers
>> two very distinct cases (cases a and b). Thse two cases should be 
>> given a name
>> so that we may easily distinguish between them
>>
>>> My proposal solves the ambiguity for both direct CRL (i.e., certificate
>>> issuer DN == CRL issuer DN) and indirect CRL.
>>
>> No there is no single solution good for everything.
>>
>>> For indirect CRL (as I
>>> responded to Stefan) requires additional trust assumptions that neither
>>> X.509 nor 3280 have.
>>
>> The zillion number of cases requires additional assumptions
>> and there may be zillions of such assumptions.
>>
>> :-)
>>
>> The case where the CA is the CRL issuer is straightforward:
>>
>> If a certification path is may be constructed, then the same sequence 
>> of DNs
>> from the same root key MUST be used to verify the signature of the CRL.
>>
>> The case where the CA designates a CRL issuer and where that CRL issuer
>> is only issuing certificate revocation status for that single CA has 
>> been described
>> in my previous e-mail.
>>
>> If we can first discuss and agree on these two cases, then, and only 
>> then,
>> we may discuss the zillion number of cases, probably for eternity.
>>
>> :-)
>>
>> Denis
>

Regards,

Denis Pinkas

---

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 17 Jun 2005 08:48:50 +0100

James,

You perfectly got the point.

Thank you for expressing it in a different way.

> Denis Pinkas wants to distinguish:

> * An indirect CRL that covers certificates from only one CA; from
> * An indirect CRL that covers certificates from more than one CA.

> David Cooper and Santosh Chokhani don't see this as a useful distinction. 

> Perhaps I can have a stab at why Denis might want the distinction.  
> It comes down to names and the namespace in which they are unambiguous.  
> The minimal assumption is that names are only unambiguous in the context 
> of the CA that certified them.  That is, a CA defines its own namespace.

> With an indirect CRL covering certificates from only one CA, we can chose that CA 
> as the single namespace.  As long as all the names being matched come from 
> that namespace we have a CRL validation solution with unambiguous names 
> and no extra assumptions.  We can achieve this if the CRL issuer's own certificate 
> comes from that CA (and the CA includes its own name in its own namespace).

> With an indirect CRL covering certificates from more than one CA there is no longer 
> a single CA to provide the namespace for all names being matched.  

> Consequently, the minimal assumption that names are only unambiguous 
> in the context of one CA is no longer sufficient.

>James

Denis

---

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 17 Jun 2005 10:28:54 +0100

Stephen,

>Denis, Santosh,

>I've love to chime in here with comments on
>draft-pinkas-zillions-00.txt and/or
>draft-chokhani-solution-00.txt but I
>can't seem to find those documents ;-)

My whole remaining life would never be sufficient to write 
<draft-pinkas-zillions-00.txt>, but I could possibly write 
<draft-pinkas-2CRLcases-00.txt> which would be much shorter.  

The "security considerations section" could however address 
the issue of the zillions cases  ... and solve of or two of them. 

:-)

>Any chance you can write up your approaches
>in the IETF preferred way? Given that the
>discussion has been going on so long already,
>I'd say the overhead of using xml2rfc, or
>whatever tool you prefer, is now acceptable
>and might allow for a much better discussion
>in Paris and on the list.

Certainly first a nice corridor discussion before the WG meeting and then
Tim would you have a time slot available for a presentation from me
on the topic ?

>Note that I'm not suggesting that such documents
>necessarily need to become RFCs or PKIX work
>items, e.g. if one solution gained WG concensus
>the relevant text could be included in 3280bis.

>Stephen.

Denis

---

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 17 Jun 2005 13:03:15 +0100

David,

(text deleted)

>If CRL issuers do not issue certificates, why does section 4.1.2.4 
>include the phrase "If the certificate issuer is also the CRL issuer, ...."

 ... because I already said that this sentence was also wrong.

Once again a CRL Issuer, that is not also a CA, only issues CRLs, 
but not Public Key certificates. 

>In the past you have claimed that what you really mean is that 
>"certificate issuer" and "CRL issuer" are roles and that an entity can 
>only be acting in one of these roles at a time.  

No. This is not what I said. An entity that is both a CA and a CRL issuer 
can play both roles at the same time. 

> But, X.509 defines 
>Certification Authority as a type of entity, not as a role and the use 
>of these terms in RFC 3280 is consistent with that.

On that aspect, the current terms of RFC 3280 are consistent but incorrect. 
This is one of the reasons to build 3280bis.

>> Hence the sentence above is incorrect. According to RFC 3280,
>> the corrected sentences should be :
>>
>> A CRL cover certificates issued by one or more CAs.
>> A direct CRL is issued by the CA, while an indirect CRL is issued
>> by a CRL Issuer.

>We'll if we really want to nitpick, the term "direct CRL" does not 
>appear in either X.509 or RFC 3280.  It also seems that my initial 
>explanation of the meaning of the term "indirect CRL" was correct 
>according to X.509:

>   X.509, Clause 3.3.32:  indirect CRL (iCRL):  A revocation list that 
>   at least contains revocation information about certificates issued 
>   by authorities other than that which issued this CRL.

I already said that X.509 is not using a clear wording. 

>> Now if you wish to change the vocabulary (and we can get a consensus)
>> to say that "indirect CRLs" is restricted to the case where a CRL covers
>> certificates issued by more than one CA, this is not a problem; ... as 
>> long as we can find a name to designate the case where a CRL covers certificates
>> issued by one and only CA, ... and we can also easily make the difference
>> with the case where the CA is issuing CRLs (currently called "direct 
>> CRL").

>I never claimed that this is the meaning of "indirect CRL".  An indirect 
>CRL may cover issued issued by one or more CAs.  The only requirement is 
>that the CRL covered certificates that were issued by an entity other 
>than the issuer of the CRL.

We are having a discussion leading nowhere: you claim that a CRL Issuer 
issues Public Key Certificates (and CRLs) whereas I claim that a CRL Issuer 
only issues CRLs.

RFC 3280 states:  " CRL issuer: an optional system to which a CA delegates the
                            publication of certificate revocation lists";

I see nowhere in that sentence that a CRL Issuer is an optional system to which 
a CA delegates the publication of public key certificates. 

But, maybe, you make a very very subtle difference between an "issuer of the CRL" 
and a "CRL Issuer" ?

You wan't find a salvation in X.509 because "CRL Issuer" is used everywhere 
in that document, .. but is left undefined in section 3.

All the other sentences that you mention below have a problem related to 
the CRL Issuer definition and will need to be fixed.

Denis

>>> How does case 3 differ from case 2? How is the number of CAs whose
>>> certificates are covered by a CRL matter?
>>
>> For case 3, the CRL includes the CRL entry extension: Certificate Issuer.
>
>This is yet another false statement that you have made in the past. 
>
>Section 5.2.5 (Issuing Distribution Point) of RFC 3280 states:
>
>   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>   the CRL includes certificates issued by authorities other than the
>   CRL issuer.  The authority responsible for each entry is indicated by
>   the certificate issuer CRL entry extension (section 5.3.4).
>
>Section 5.3.4 (Certificate Issuer) of RFC 3280 states:
>
>   This CRL entry extension identifies the certificate issuer associated
>   with an entry in an indirect CRL, that is, a CRL that has the
>   indirectCRL indicator set in its issuing distribution point
>   extension.  If this extension is not present on the first entry in an
>   indirect CRL, the certificate issuer defaults to the CRL issuer.  On
>   subsequent entries in an indirect CRL, if this extension is not
>   present, the certificate issuer for the entry is the same as that for
>   the preceding entry.
>
>In case 2 above, where the CRL covers certificates issued by a single CA 
>and that CA is a different entity from the CRL issuer, the CRL is an 
>indirect CRL and the first entry in the list of revoked certificates in 
>the CRL MUST include the certificateIssuer extension.  RFC 3280 clearly 
>states that if the certificateIssuer "extension is not present on the 
>first entry in an indirect CRL, the certificate issuer defaults to the 
>CRL issuer."  In case 2, since the issuer of the revoked certificate is 
>not the CRL issuer, the certificateIssuer extension must be present to 
>identity the certificate issuer.
>
>Dave
>

Regards,

Denis Pinkas

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 17 Jun 2005 14:27:02 +0100

Denis,

The entity assuming the role of a CRL Issuer may issue certificates if
that entity is a CA.

I didn't propose any wording.
Just made an attempt to see if we could agree on the basic principle. 
And we couldn't.

So I think I resign from this one unless there is anyone else sharing
your concern.

/Stefan

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 17 juni 2005 16:14
> To: David A. Cooper; Stefan Santesson
> Cc: pkix
> Subject: Re: 3280bis: CRL validation
> 
> Stefan,
> 
> >How hard can this be?
> 
> Probably harder than you think. :-)
> 
> >CA is an entity, CRL Issuer is a role.
> 
> No. Since a CRL Issuer may also be an entity that is different from
the
> CA.
> 
> In 3280bis we simply have:
> 
> " CRL issuers issue CRLs."      Page 51.
> 
> David said:
> 
> " If CRL issuers do not issue certificates, why does section 4.1.2.4
> It is section 4.2.1.14, not section 4.2.1.4 as indicated.
> 
> This means that a CA may issue CRLs, *but not that a CRL Issuer may
issue
> certificates*.
> I am awaiting an acknowlegment from David.
> 
> >(I think this was David's point)
> 
> Maybe, maybe not.
> 
> >A CA is an entity that issues certificates and optionally assumes the
> >role of CRL Issuer.
> 
> >CRL Issuer is a role that only involves issuance of CRL.
> 
> > Normally the CA
> >acts also as CRL Issuer but it can also delegate this role to another
> >entity.
> 
> >Can you agree with this principle Denis?
> 
> No. I can't agree with your proposed wording. See above.
> 
> Denis
> 
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
>

---

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 17 Jun 2005 15:14:15 +0100

Stefan,

>CA is an entity, CRL Issuer is a role.

No. Since a CRL Issuer may also be an entity that is different from the CA.

David said:

This means that a CA may issue CRLs, *but not that a CRL Issuer may issue certificates*.
I am awaiting an acknowlegment from David.

Maybe, maybe not.

Denis

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 17 Jun 2005 21:22:59 +0100

If you read the sentence it says "the CAs it supports", not "globally"

It's not the matter of what the CA can do. It is the matter of what
names it chooses to assert.

/Stefan

> From: David Chadwick [mailto:[email-masked]]
> Sent: den 17 juni 2005 17:58
> To: Stefan Santesson
> Cc: Manger, James H; pkix
> Stefan Santesson wrote:
> > Of natural necessity a CRL Issuer need to make sure that all CAs it
> > supports has different DNs.
> 
> So if CAs can be sure to have globally unique DNs (which is what
> "different" implies), then why cant their subjects?
> 
> Regards
> 
> David
>

---

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 20 Jun 2005 13:53:30 +0100

Stefan,

(some text deleted)

(...)

>Further,
>I have an alternative to Denis view of case a) and b)

>If we simply view every CRL in the context of the certificate we are
>checking for validity, then we can have only 1 rule set (only one case
>in terms of RP processing rules).

>That is, the name of the CRL issuer should be viewed within the context
>of the CA that issued the cert we are validating, and revocation
>information related to other CAs is simply ignored.

>Any restrictions on path relationship between CRL and certificate will
>be enforced by the relying party solely in the context of the
>certificate it validates.

>supports has different DNs.

Agreed.

This is nicely expressed in a nutshell. 

Denis

>> On Behalf Of David Chadwick
>> Sent: den 17 juni 2005 11:44
>> To: Manger, James H
>> Cc: pkix
>> Oh dear. The same old problem of namespaces again. X.500 makes it very
>> clear that there is only one namespace for all Distinguished names, so
>> CAs cannot invent their own DNs in isolation to the rest of the world.
>> If they do, then their domain is the entire universe of distinguished
>> names and they cannot expect to interwork with any other CA without
>> experiencing name collisions.
>> 
>> Twenty years ago we had the same problem with people inventing their
>own
>>   domain names and IP addresses on their LANs. Then they wondered why
>> things did not work correctly when they tried to connect to the rest
>of
>> the world via the Internet. Surprise, surprise, they had to get
>globally
>> unique domain names and IP addresses in order to interwork properly.
>> 
>> It is the same today with CAs and X.500 distinguished names. Fullstop.
>> End of discussion
>> 
>> regards
>> 
>> David
>> 
>> 
>> 
>> Manger, James H wrote:
>> > Denis Pinkas wants to distinguish: * An indirect CRL that covers
>> > certificates from only one CA; from * An indirect CRL that covers
>> > certificates from more than one CA. David Cooper and Santosh
>Chokhani
>> > don't see this as a useful distinction.
>> >
>> >
>> > It comes down to names and the namespace in which they are
>> > unambiguous.  The minimal assumption is that names are only
>> > unambiguous in the context of the CA that certified them.  That is,
>a
>> > CA defines its own namespace.
>> >
>> > With an indirect CRL covering certificates from only one CA, we can
>> > chose that CA as the single namespace.  As long as all the names
>> > being matched come from that namespace we have a CRL validation
>> > solution with unambiguous names and no extra assumptions.  We can
>> > achieve this if the CRL issuer's own certificate comes from that CA
>> > (and the CA includes its own name in its own namespace).
>> >
>> > With an indirect CRL covering certificates from more than one CA
>> > there is no longer a single CA to provide the namespace for all
>names
>> > being matched.  Consequently, the minimal assumption that names are
>> > only unambiguous in the context of one CA is no longer sufficient.
>> >
>> > James
>> >
>> >
>> 
>> --
>> 
>> *****************************************************************
>> David W. Chadwick, BSc PhD
>> Professor of Information Systems Security
>> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
>> Tel: +44 1227 82 3221
>> Fax +44 1227 762 811
>> Mobile: +44 77 96 44 7184
>> Email: [email-masked]
>> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>> Research Web site: http://sec.cs.kent.ac.uk
>> Entrust key validation string: MLJ9-DU5T-HV8J
>> PGP Key ID is 0xBC238DE5
>> 
>> *****************************************************************
>
>

Regards,

Denis Pinkas

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 21 Jun 2005 10:01:06 +0100

Thank you David for the job to dig up these references.

But I have yet to see the concept of Globally Unique expressed in any requirement.

First interesting observation is that X.501 builds its model around objects in "The Directory". So that must mean globally, right? (or it should be named "A Directory". Well, X.501 does not give that message in its introduction saying;

"This Recommendation | International Standard, together with the other Recommendations | International Standards, has been produced to facilitate the interconnection of information processing systems to provide directory services. A set of such systems, together with the directory information that they hold, can be viewed as an integrated whole, called the Directory."

I admit that I have not read the whole X.501 line by line, (who has?) but this rather important sentence suggest that this is not at all "globally unique" it is only "A set of such systems"

In this context the distinguished name is only a name that is unambiguous within the directory, which just refers to "A set of such systems".

For what it's worth, I searched the whole X.501 for the word "unique" and got very few hits, none of them relevant to this subject. "Global" and "unambiguous" gave 0 hits

BUT

No matter how we turn X.501 around, we do not have a reality in which unique names exist for sure. We live in a world where we define contexts we can control and at best we name objects unambiguously within them. In the practical use of X.509 every CA can only know for sure that it assigns unique names within its own real or imaginary DIT or a DIT within which it consciously operates. 

In the world of cross certification we may cross borders of different real or imaginary directory systems and DN collisions may occur.

In my mind, RFC 3280bis must take this into account when formulating its security guidance.

Stefan Santesson

> From: David A. Cooper [mailto:[email-masked]]
> Sent: den 20 juni 2005 22:59
> To: Stefan Santesson
> Cc: pkix
> > 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.
> 
> X.509, Clause 8.3.2.1 (Subject alternative name extension):
> * The values in the alternatives of the GeneralName type are names of
> various forms as follows:
> directoryName is a directory name defined in accordance with ITU-T Rec.
> X.501 | ISO/IEC 9594-2;
> 
> * For every name form used in the GeneralName type, there shall be a
> name registration system that
> ensures that any name used unambiguously identifies one entity to both
> * It is recommended that, provided the subject field of the certificate
> contains a directory name that
> unambiguously identifies the subject, this field be flagged non-critical.
> 
> X.509, Clause 8.3.2.2 (Issuer alternative name extension): It is
> recommended that, provided the issuer field of the certificate or CRL
> contains a directory name that unambiguously identifies the issuing
> authority, this field be flagged non-critical.
> 
> 
> 
> X.501, Clause 9.1.4 (definitions): (directory) name: A construct that
> singles out a particular object from all other objects. A name shall be
> unambiguous (that is, denote just one object), however it need not be
> unique (that is, be the only name which unambiguously denotes the object).
> 
> X.509, 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,
> (directory) name also identifies an
> entry. This entry is either an object entry that represents the object
> or an alias entry which contains
> information that helps the Directory to locate the entry that represents
> the object.
> 
> NOTE 1 – The set of names of an object thus comprises the set of alias
> names for the object, together
> with the distinguished names of the object.
> 
> An object can be assigned a distinguished name without being represented
> by an entry in the Directory,
> but this name is then the name its object entry would have had were it
> represented in the Directory.
> 
> Syntactically, each name for an object or entry is an ordered sequence
> of relative distinguished names (see 9.3).
>

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 21 Jun 2005 11:33:11 +0100

Stefan,

I agree with your explanations and we share the same views on this topic.

You said : "RFC 3280bis must take this into account when formulating its security guidance".

I would go one step further and say :

"RFC 3280bis must make sure that DN name collisions (whether accidental or voluntary) 
do not introduce security breaches". 

Denis

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 21 Jun 2005 11:11:04 +0100

I just want to correct my stupid mistake before someone else does :)

My search engine tricked me when I surprisingly didn't get a hit on "Global" or "unambiguous" but there are indeed lots of hits on those words in X.501.

(What really I meant was that there were no occurrences of those words in italic format) :)

Interestingly X.501 uses the term "The Global DIT" but I find no definition of what that really means for the concept as a whole.

It suggest to me that the directory model indeed is built around names with a global scope, but that the introduction in my mind opens up for the possibility of parallel universes (unrelated directory systems) that despite its global scope of naming may by coincident assign the same name to different objects.

Now I'm ready for the X.500 gurus to slap my fingers.

/Stefan

> From: Stefan Santesson
> Sent: den 21 juni 2005 11:01
> To: 'David A. Cooper'
> Cc: pkix
> First interesting observation is that X.501 builds its model around
> objects in "The Directory". So that must mean globally, right? (or it
> should be named "A Directory". Well, X.501 does not give that message in
> its introduction saying;
> 
> "This Recommendation | International Standard, together with the other
> Recommendations | International Standards, has been produced to facilitate
> the interconnection of information processing systems to provide directory
> services. A set of such systems, together with the directory information
> that they hold, can be viewed as an integrated whole, called the
> Directory."
> 
> I admit that I have not read the whole X.501 line by line, (who has?) but
> this rather important sentence suggest that this is not at all "globally
> unique" it is only "A set of such systems"
> 
> In this context the distinguished name is only a name that is unambiguous
> within the directory, which just refers to "A set of such systems".
> 
> For what it's worth, I searched the whole X.501 for the word "unique" and
> got very few hits, none of them relevant to this subject. "Global" and
> "unambiguous" gave 0 hits
> 
> BUT
> 
> No matter how we turn X.501 around, we do not have a reality in which
> unique names exist for sure. We live in a world where we define contexts
> we can control and at best we name objects unambiguously within them. In
> the practical use of X.509 every CA can only know for sure that it assigns
> unique names within its own real or imaginary DIT or a DIT within which it
> consciously operates.
> 
> In the world of cross certification we may cross borders of different real
> or imaginary directory systems and DN collisions may occur.
>

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 21 Jun 2005 14:05:13 +0100

>David Chadwick,

>Would not it be better to solve the "World Hunger".  

What are you speaking of :

  - www.worldhunger.org/       ?
  - www.thehungersite.com/    ?
  - www.worldhungeryear.org/ ?
  - something else                 ?

:-)

Denis

>At least this could be
>my redemption.  
>Sent: Friday, June 17, 2005 12:01 PM
>To: Santosh Chokhani
>Cc: 'pkix'
>Santosh Chokhani wrote:
>> The problem I am trying to solve is obtaining correct revocation 
>> information when CA and CRL Issuer names are not guaranteed to be 
>> globally unique.
>
>Santosh
>
>whilst you are at it, can you also please solve the problem of how to 
>deliver email to two different people who have the same email address, 
>and two different computers that have the same IP address.
>
>thanks
>
>David

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 21 Jun 2005 17:20:39 +0100

David;

> On Behalf Of David A. Cooper

> (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).

Could you find for me the quote that support this "globally unambiguous"
claim?

In my attempts I have only found support that each object must be
unambiguously named within the directory while X.501 states that "the
directory" is "A set of directory services systems".

/Stefan

---

From: Sharon Boeyen <[email-masked]>
Date: Tue, 21 Jun 2005 13:59:23 -0400

Denis that is definitely a misinterpretation of X.509 - Full Stop.

I think Dave Cooper has shown sufficient quotes to prove this fact. What I
think is true is that there does not exist a single authority globally to
ensure that DNs are unambiguous. That does not mean the assumption isn't
there in X.509 - it most definitely is. What it does mean is that, depending
on the type of DNs used and how they are structured, it may/may not be more
difficult to ensure uniqueness. It does NOT mean name collisions should be
expected.

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Tuesday, June 21, 2005 5:33 AM
To: David A. Cooper
Cc: pkix
Subject: Re: 3280bis: CRL validation

David,

>> 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.

>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

>NOTE 1 ? The set of names of an object thus comprises the set of alias
>represented

Regards,

Denis Pinkas

---

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 22 Jun 2005 16:36:51 +0100

Sharon,

Thank you for your long explanation. At the end of your e-mail you say:

So regardless of whether or not one believes X.509 assumes unambiguous DNs (again as ex-editor and chair of the X.509 debates from 1993 - 2003 I'd like to assure you that was the intent), there is a real world possibility that two entities may end up using the same DN, primarily because of the failure to set up comprehensive and effective registration authorities for DNs as well as use by rogue entitles. 

Understanding that such an unintended situation might occur accidentally or through the efforts of a rogue entity, is certainly very different from rewriting a standard to allow it to occur as a normal situation. 

[Denis]: It seems that are now close to an agreement. 

We need to describe how to achieve security in such a "real world" situation.

Of course, a name collision is not a normal situation and CAs should use DN constructed 
with a sufficient number of attributes so that a name collision is unlikely to happen, at least by accident.

In case of a deliberate name collision, relying parties shall be able to make the difference 
by realizing that the certification paths are different.

Denis

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 22 Jun 2005 10:04:16 -0400

Hi Stefan,
 
The "of interest" type wording is, I believe, meant to indicate that not all
objects will end up being in the Directory. That doesn't mean that their DNs
don't still need to be unambiguous. 
 
My firm belief, and this is from sitting in X.500 meetings from 1987 until
about 2003 (many discussions I chaired), and listening to the heated debates
and the conclusions of those meetings, is that the intent of DNs is that
they unambiguously name objects regardless of whether or not those objects
ever appear in "the" Directory. As mentioned by David, there have been
several attempts, primarily by Denis, to have X.509/501 change this intent
to make DNs unambiguous within the namespace that a single CA issues
certificates. Those attempts have consistently failed. 
 
One thing we did try to do in X.509 in the 4th editions was to try to make
it a standalone document and reduce its dependencies on the other parts of
the X.500 series so that people who wanted to implement X.509 but not the
directory would not have to use the whole set of documents. We succeeded in
some cases (e.g. moved attributes and object classes from X.520 and X.521
for example) but the successes were limited to topics that affected X.509
and not general directory implementations. The concept of DNs and that of
matching for DNs is one that is very central to BOTH X.509 and general X.500
directory services and therefore it had to stay in X.501. We considered
duplicating text and removing the directory references for X.509 but that
would have been too difficult to do and to maintain. So we're left with
X.501 which needs to include the directory wording for those implementers.
However I (and many others in those meetings)I thought the text was clear
enough to separate the two. Obviously others feel differently.
 
However, regardless of that, it is true that the corresponding standards for
name registration that ITU and ISO approved have not been universally
adopted. Had they been, we'd have had a solid integrated registration system
that would have ensured DNs were exactly that (globally unambiguous names
for objects). A few countries did set up registration authorities but the
fees were at least one reason they didn't get a lot of business. Note that
in Canada the service is free and is still not getting a lot of business.
dc-based DNs are another way to drive the unambiguous requirement, but they
are not universally adopted either. So regardless of whether or not one
believes X.509 assumes unambiguous DNs (again as ex-editor and chair of the
X.509 debates from 1993 - 2003 I'd like to assure you that was the intent),
there is a real world possibility that two entities may end up using the
same DN, primarily because of the failure to set up comprehensive and
effective registration authorities for DNs as well as use by rogue entitles.
Understanding that such an unintended situation might occur accidentally or
through the efforts of a rogue entity, is certainly very different from
rewriting a standard to allow it to occur as a normal situation. 
 
Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 8:59 PM
To: Sharon Boeyen; Denis Pinkas; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

Sharon,

I fairness I don't think anything has been shown until my last comments and
quotes from X.501 has been responded to.

Let me therefore expand on this (hopefully for the last time).

What seems to cause confusion is in particular the following quote:

>unique (that is, be the only name which unambiguously denotes the object).

What we need to understand is what the context is, in which the term
"object" is to be understood.

Does this refer to objects in a defined context (such as objects of a
directory) or does this mean all possible objects in the world we know?

X.501 in my reading suggests the former and I would like to suggest 3 quotes
to support that:

1) The introduction of X.501 which sets the context of the standard and
defines "the directory"

that they hold, can be viewed as an integrated whole, called the Directory."

This sets the context of the standard and states that "the Directory" is
just "a set of such systems", which not at all is the same as the whole
world.

2) The section defining the concept of objects (section 7.2) starts:

"The purpose of the Directory is to hold, and provide access to, information
about objects of interest (objects) which exist in some 'world'. An object
can be anything in that world which is identifiable (can be named)."

This clearly states that objects in the context of this standard is limited
to "objects of interest" that reflect "some 'world'", not all possible
objects and not the entire world.

3)  Section 9.2 finally sets naming of objects to be tied to the context of
the directory.

An object can be assigned a distinguished name without being represented by
an entry in the Directory, but this name is then the name its object entry
would have had were it represented in the Directory.

Conclusion:

If we recognize "the directory" as one of many possible directory systems,
and recognize that each directory system (reflected in a real directory or
just as a virtual DIT) can be served by one or more valid CAs who issues
certificates in support of that system, then all quotes presented so far are
compatible with the fact that 2 unrelated and compliant CAs may assign the
same DN to different subjects

Neither X.509, nor RFC 3280 states that all CAs in the world MUST support a
common directory (a common DIT).

This is also in line with how in fact the real world works and that is hard
to neglect.

Stefan Santesson 

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: den 21 juni 2005 19:59
To: 'Denis Pinkas'; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

Cheers, 
Sharon 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Denis Pinkas 
Sent: Tuesday, June 21, 2005 5:33 AM 
To: David A. Cooper 
Cc: pkix 
Subject: Re: 3280bis: CRL validation 

David, 

Denis 

Regards, 

Denis Pinkas

---

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 20 Jun 2005 13:53:30 +0100

Stefan,

(some text deleted)

(...)

Agreed.

Denis

Regards,

Denis Pinkas

---

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Jun 2005 11:33:32 -0400

Stefan,

When X.500 speaks of THE DIT as a system, it is referring to the 
notion that there are many directories which together provide an 
unambiguous, global directory system.  It is not suggesting parallel 
universes, each with its own DIT, although that is closer in practice 
to what we have for DNs. The DNS is precisely what X.500 envisioned 
as a global directory, with a single root, per-country 2nd tier 
subtrees, etc. What DNS lacks, relative to X.500, is attribute-tagged 
name components, in terms of name forms. (And, as an historical 
accident, we have the non-cc TLDs, for better or worse.) The DNS also 
was built with more modest goals, so it does not have, in its basic 
form, entries that are as rich in detail as X.500 entries, although 
we have added record types to allow for storing lots of other data 
types over time.

For PKI purposes, we need to accommodate the reality that DNs may not 
be globally unique, either because of the lack of a rigorous, global 
RA capability, or because of malicious intent. Let's just accept 
these are facts of life that we have to accommodate and move on. What 
we need to do is to try to minimize the opportunities for cert 
validation to be undermined by these possible exceptions to the 
notion of globally unique DNs, and to carefully document the residual 
vulnerabilities where we cannot provide viable technical 
countermeasures.

Steve