[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: X.509, PKIX, and pathLenConstraint
David
I think that the truth of the matter is that the scenario you present
below was never discussed or thought about at the X.509 meeting
(certainly not one that I can recall). It is one of those exceptional
cases that causes one to have to re-evaluate the wording in the
standard. But before we can get the wording correct, we first have to
decide what should be the desirable/correct outcome of such an unusual
scenario.
It seems to me that CA3 in your example is not a certification authority
in our usual meaning of the term (i.e. a certificate issuer), but is
rather a "revocation authority". If CA3 were a certification authority,
then any certificates it issued would not be trusted by the RPs of CA1.
However, neither is CA3 an end entity, since end entities are not
allowed to issue revocation lists (it must be an authority, see text
from 7.3 below). Thus one solution would be to update Basic Constraints
and to have 3 classes of entities in there, namely CAs, RevAs, and EEs.
At present we simply have a boolean, which indicates CA or not CA.
My hypothesis that we need to define a new type of authority is further
supported by the text in 8.4.2.1 which states
The cA component indicates if the certified public key may be used to
verify certificate signatures.
This definition does not include any mention of verifying revocation
lists, therefore one could argue that if CA is false the subject could
be a RevA or an EE. Therefore Basic Constraints needs to differentiate
between a RevA and an EE. ONce this is done, the solution to the problem
is simple.
If CA3 is a CA, reject the CRL
If CA3 is an EE, reject the CRL
If CA3 is a RevA, accept the CRL
Here is the text that describes the certification authority in 7.3
The authority that issues certificates (public-key or attribute) also
has the responsibility to indicate the validity of certificates it
issues. Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate. An authority that issues certificates is
required to state, possibly through a published statement of their
practices, through the certificates themselves, or through some other
identified means, whether:
- The certificates cannot be revoked; or
- The certificates may be revoked by the same certificate-issuing
authority directly; or
- The certificate-issuing authority authorizes a different authority to
perform revocation.
David (Chadwick)
"David A. Cooper" wrote:
>
> For those of you who have not been following the PKIX mailing list,
> there has been a debate recently on the proper semantics for the
> pathLenConstraint field in the basicConstraints certificate extension.
> I believe the intention of pathLenConstraint was to limit the number
> of intermediate certificates in a path, but others disagree. I have
> been arguing my point on the PKIX list, but am afraid that I am losing
> the argument. In the end, I think that either interpretation of
> pathLenConstraint would be acceptable, but it is very important that
> X.509 and PKIX are consistent, and I believe that the solution PKIX is
> leaning towards is contrary to X.509 and is also inconsistent with the
> text of Defect Report 272
> (ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf),
> which will be sent out for ballot in the near future.
>
> From what I can tell, the decision in PKIX will not be made on the
> basis of which semantics are better, but on the general consensus as
> to which semantics were the "original" ones. So, if you have an
> opinion on this topic, please post a message on the topic to the PKIX
> list so that we can avoid a divergence in the standards.
>
> The point of contention in this debate can be seen by looking at the
> sample certification paths below. In in diagram, CA1 has issued a
> cross-certificate to CA2 and has included a pathLenConstraint to
> ensure that its relying parties only validate end entity certificates
> issued by CA2. CA2 issues end entity certificates, but has also issued
> a cross-certificate to CA3 so that CA2's relying parties can accept
> certificates issued by CA3. In addition, CA2 includes in its own end
> entity certificates a cRLDistributionPoint stating that revocation
> information for the certificates issued by CA2 should be obtained from
> CA3.
>
> CA1
> | basicConstraints:
> | cA=TRUE
> | pathLenConstraint=0
> |
> | keyUsage:
> | keyCertSign, cRLSign
> |
> |
> \ / keyUsage: digitalSignature
> CA2
> ------------------------------------------------------------------------->
> EE
> | cRLDistributionPoints:
> | cRLIssuer: CA3
> |
> | basicConstraints:
> | cA=TRUE
> |
> | keyUsage:
> | keyCertSign, cRLSign
> |
> \ /
> CA3
>
> Everyone is in agreement that CA1's relying parties should validate
> the certificate issued to EE. There is disagreement, however, over
> whether CA1's relying parties should validate CRLs issued by CA3
> (which is necessary to determine the status of the certificate issued
> to EE).
>
> In order to validate CRLs issued by CA3, CA1's relying parties would
> first attempt to validate the certification path CA1--->CA2--->CA3.
> The problem is that X.509 states that
>
> [pathLenConstraint] gives the maximum number of
> CA-certificates that may
> follow this certificate in a certification path. Value
> 0 indicates that the subject
> of this certificate may issue certificates only to
> end-entities and not to further CAs.
>
> If the certificate issued by CA2 to CA3 did not include
> basicConstraints with cA=TRUE, then everyone would agree that that
> certificate was a end-entity certificate and that the path
> CA1-->CA2-->CA3 should validate. Some people argue, however, that
> since the certificate includes basicConstraints with cA=TRUE that the
> certificate is a CA-certificate and that since the inclusion of
> pathLenConstraint=0 in the preceding certificate means that CA2 may
> issue certificates only to end-entities, the certificate issued to CA3
> should be rejected. Unfortunately, this would mean that CA1's relying
> parties could not validate CRLs issued by CA3 and so could not
> determine the status of the certificate issued by CA2 to EE, even
> though they could validate the certificate itself.
>
> While a careful reading of the quote from X.509 above would seem to
> suggest that the certification path CA1-->CA2-->CA3 should be
> rejected, I do not think this was the intended interpretation of
> pathLenConstraint. I you read Defect Report 272, for example, it
> states that "[t]he [path length] constraint controls the number of non
> self-issued CA certificates between the CA certificate containing the
> constraint and the end-entity certificate." This sentence suggests
> that the description of pathLenConstraint was written with the
> assumption that every certification path would end with an end-entity
> certificate and that the true goal of pathLenConstraint was to limit
> the number of non self-issued intermediate certificates in a
> certification path. In other words, the certification path
> CA1-->CA2-->CA3 should be validated since in this certification path
> CA3 is playing the role of an end-entity, not a CA, and so the
> certificate CA2-->CA3 should be treated as an end-entity certificate
> when validating this path.
>
> I believe that this was not only the original intention when defining
> pathLenConstraint but also that it is the better interpretation as a
> result of potential scenarios such as the one shown above. As I
> mentioned before, however, it appears that PKIX is leaning towards
> adopting an interpretation of pathLenConstraint that would result in
> the reject of the path CA1-->CA2-->CA3. If you believe this is
> incorrect, please make your opinion known to the PKIX list. Otherwise,
> we will need to change X.509 and DR 272 in order to avoid a divergence
> between the standards.
>
> Dave
--
*****************************************************************
David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351 Fax +44 161 745 8169
*NEW* Mobile: +44 77 96 44 7184 *NEW*
Email: D.W.Chadwick@xxxxxxxxxxxxx
Home Page: http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500: http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:d.w.chadwick@xxxxxxxxxxxxx
x-mozilla-cpt:;11160
fn:David Chadwick
end:vcard