Re: 3280bis: CRL validation

["David A. Cooper" <david.cooper@xxxxxxxx>]

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.

X.509 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;

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

   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.

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

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

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.

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

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.

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.

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

Note that I am personally in favor of Santosh's proposal, 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, 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