Denis,
As the previous editor of X.509 and as the previous editor of the general X.500 series, I respectfully disagree with your opinion and strongly support David's argument about naming, with the caveat that X.500 and X.509 DNs are unamibuous names (ie the name can only represent a single entity) rather than unique names (ie it is the ONLY name for an entity). I remember very well the debate that David mentions and I fully support his representation of its conclusion. This is not a debate we should be re-hashing here.
As was mentioned several times during that earlier debate, the standard can do nothing about CAs that do not follow the model and yes it is possible for a CA to do so, but that would be contrary to the standard (as many other behaviours of CAs would also be).
I will resist going further into the debate because, as David mentions, this was done already several years ago.
Cheers,
Sharon
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
Sent: Friday, June 03, 2005 11:19 AM
To: David A. Cooper
Cc: pkix
Subject: Re: 3280bis: CRL validation
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
>
>
>