I note the issue of DN Conventions for CAs on the agenda. I cannot be
at the PEM meeting Monday, but hope someone else from BNR can be
there to address the topic. Following is my summary of the issue and
some recommendations.
The main problem is as follows:
- The PEM name subordination rule requires that, in any certificate
(except one signed by the IPRA or a PCA), the DN of the CA must be
superior in the X.500-naming sense to the DN of the subject. This is
to give a certificate user reasonable asurance that the CA is
authorized to sign that particular certificate.?
- This rule makes it difficult to use PEM in conjunction with a natural
X.500 naming structure, e.g., in an organization that uses X.500 for
other purposes.?
Consider, for example, the name tree for the organization <C=CA,
O=BNR>. Two appraches to CA naming are:
?
(a) Make the CA name = <C=CA, O=BNR>. Name subordination works fine,
but we have forced the CA to have the same DN (hence the same Directory
entry) as the Organization itself. This is problematical because
entries for CAs and Organizations generally have different object
classes, need different attributes, and need different values of some
attributes (e.g., telephone number)?.
(b) Make the CA name = <C=CA, O=BNR, OU=Our Cert. Authority>. This
forces unnatural user names for the organizational users, e.g., <C=CA,
O=BNR, OU=Our Cert. Authority, CN=W.Ford>, and virtually necessitates
alias entries for all users.
In addition, it is not possible to have multiple CAs with distinct key
pairs covering the same name subtree. This is a real requirement that
I have expounded upon previously.
As a long-term solution to this problem, the addition of optional
non-distinguished attributes to certificates (along the lines suggested
by Bob Jueneman) seems to fit the bill nicely. Following is one
possible way to use such an attribute:
- Define a (possibly multi-valued) attribute "AuthorizedSubtree", for
use in a certificate which certifies a CA's public key. Each value is
the root of a name subtree for which the CA is authorized to issue
certificates.?
- Possible new name subordination rule: In checking the certificate
for subject s signed by issuer i, first inspect the certificate for i's
public key. If that certificate contains an AuthorizedSubtree
attribute, then check that s is name-subordinate to the identified
subtree. If no such attribute, use current name subordination check.?
- Restrict a CA such that it cannot authorize subordinate CAs outside
its authorized subtree. PCA rules may vary with policy.?
Example, with organization <C=CA, O=BNR>. The CA name can be <C=CA,
O=BNR, OU=Our Cert. Authority>. The certificate for this CA (as signed
by a superior CA or PCA) can contain the non-distinguished attribute
AuthorizedSubtree = <C=CA, O=BNR>.?
?
RECOMMENDATION: Proceed with the extended certificate format proposal
(seeking PEM and ISO/IEC agreement on the new format) and include a
definition of an attribute satisfying this need.
In addition to such a long-term solution, I believe we should seek, for
the short term, a temporary work-around which does not require a
certificate format change. This work-around would involve specifying
appropriate CA-naming conventions, and should be backward compatible
with current conventions and name subordination rule.?
?
Several possibilities have been raised on pem-dev:
?
(1) New naming attribute, e.g., <CA=...>, used as RDN wrt an
"associated node". Name subordination applies wrt the DN of the
"associated node", rather than the DN of the CA itself.?
Example, with organization <C=CA, O=BNR>: The CA name can be <C=CA,
O=BNR, CA=Our Cert. Authority>. Name subordination is based on the
name of the "associated node", i.e. <C=CA, O=BNR>.?
(At the same time can also add <PCA=...>, which gives a new simple
way of recognizing if a certificate is signed by a PCA, a CA, or
neither.)
Objection: Adding a new distinguished attribute type may disturb some
existing DSAs and/or DUAs.
(2) Special convention regarding use of some existing attribute type,
e.g., object class, role occupant, or common name.?
Example using common name:? If a CA name contains a final RDN of the
form <CN=...>, then this RDN is stripped before applying the name
subordination rule. Otherwise, use existing name subordination rule.?
Example, with organization <C=CA, O=BNR>: The CA name can be <C=CA,
O=BNR, CN=Our Cert. Authority>. Name subordination is based on the
name with CN RDN stripped, i.e. <C=CA, O=BNR>.?
(NOTE: Migration to this scheme is straightforward provided existing
PEM CAs do not have a CN RDN. If this is a problem, find another
attribute type. The PCA operators can probably give a good indication
of what attributes are being used currently in CA names.)?
(3) Introduce convention wrt to the value in some attribute, e.g., an
OU name commencing with the characters "Cert. Authority" indicates a CA
RDN. Objections: No guaranteed uniqueness. Not natural in
non-English language.?
?
RECOMMENDATION: Pursue a short-term solution based on (2).
Warwick Ford
?????????????????????????????????