[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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