[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Open Issue in Part1: path length constraints
Title: Re: Open Issue in Part1: path length
constraints
David,
Steve,
From a policy point of view, it may make
sense to say that only CAs should be issuing CRLs, but what does this
mean from a certificate path processing point of view?
I have to admit that I have not thought as much about the path
processing aspect of the issue.
X.509 states "[t]he cA component indicates
if the certified public key may be used to verify certificate
signatures". It says nothing about CRLs. Similarly, as you note,
RFC 2459 ties keyCertSign to CA certificates but does do so with
cRLSign. Are you arguing that we should change the standards to
require basicConstraints with cA=TRUE in certificates that only
authorize the use of the subject's public key to verify signatures on
CRLs? Or are you suggesting that a certificate should be treated as a
CA certificate if cRLSign is set in keyUsage even if basicConstraints
is absent?
I have always expected to see the CA flag set to true on a cert
used to sign CRLs, but, as I noted in my message, a closer look at
2459 fails to require that. Still, throughout most of the document we
see references to CAs, not to EEs, with regard to CRL signing. If
there was an intent to allow non-CAs to sign CRLs, we certainly did
not make it clear.
Until we had the KeyUsage extension and the the certSign bit in
v3 certs, there was no doubt that only a CA could sign a CRL. It was
not clear to me that X.509, or 2459, made a point of advertising that
a feature of this extension, and of indirect CRLs, was to promote the
signing of CRLs by other than a CA. Rereading the 259 text, I still
have to say that is not a message that comes through.
To be more specific, if we accept the
idea that pathLenConstraint should be computed differently depending
on what type of certificate the last one in the path is, should CA1's
relying parties accept CRLs issued by CA3 in the certification path
below?
CA1 ----------------------------> CA2
----------------------------------> CA3
basicConstraints:
keyUsage:
cA=TRUE
cRLSign
pathLenConstraint=0
keyUsage:
CRLDistributionPoints:
keyCertSign, cRLSign
cRLIssuer: CA3
I would say no, if I understand your diagram. First, the cert
from CA2 to CA3 does not say that CA3 is a CA! Also, if the
distribution point extension is in the cert issued by CA2 to CA3, it
is a statement about where to find the CA3 cert if it is ever revoked.
If the distribution point were in certs issued by CA2 to EEs, then it
would be saying that CA3 would be the issuer of these CRLs. But, look
at the text below, from 2459
5.2.5
Issuing Distribution Point
The
issuing distribution point is a critical CRL extension
identifies the CRL distribution point for a particular CRL, and it
indicates whether the CRL covers revocation for end
entity
certificates only,
CA certificates only, or a limitied set of reason codes.
Although the extension is critical, conforming implementations are not
required to support this extension.
The CRL is signed using the CA's private key. CRL
Distribution
Points do not have their own key pairs. If the CRL is stored in
the X.500 Directory, it is stored in the Directory entry corresponding
to the CRL distribution point, which may be different than the
Directory entry of the CA.
This explicitly refers to the CRL being signed with a CA private
key, not an EE private key.
Steve