Bob, Warwick, Rhys and Folk
CA-Naming ... Well, I particularly think you are trying to solve a
problem that is a side-effect of a higher one, that is the "Naming
Hierarchy".
At this stage of the discussion, there is still a point I have not
completely clear, and perhaps this can be the starting point of my
rationale:
"Which is your main argument in support of a certification hierarchy
expressed in terms of a naming hierarchy?"
The arguments I know are those enclosed in RFC-1422 and others I have
repeatedly read in the list. Let me reproduce them:
-----
RFC-1422:Section 3.1. Architecture. Scope and Restrictions
1) "The proposed architecture imposes conventions for the certification
hierarchy which are not strictly required by the X.509 recommendation
nor by the technology itself. These conventions are motivated by several
factors, primarily the need for authentication semantics compatible with
automated validation and the automated determination of the policies
under which certificates are issued."
2) "These conventions minimize the complexity of validating user
certificates, e.g., by making explicit the relationship between a
certificate issuer and the user (via the naming hierarchy)."
From the list:
a) "This is to give a certificate user reasonable assurance that the CA
is authorized to sign that particular certificate."
b) Similar to a), "Control issuer-to-subject relationship. For instance,
control that an employee of one company has not been issued with a
certificate from another company."
-----
Are these your main arguments too?
However, PEM is not my understanding of a clean/pure certification name-
based hierarchy. I can or can not agree with X.509 recommendation
(hierarchical example) and ANSI X9.30, but they do really state a pure
certification hierarchy in terms of DIT naming. PEM's PCAs and IPRA
break this cleanness.
In PEM, you have the hierarchy explicitly expressed in DNs of users and
CAs certificates (Organizational, residential,...), so you can argue 1),
2), a) and b). But as far as you get a top CA (just before policy
level), you have not explicit hierarchy information any more. Hence the
constrain: CAs under different policies have to use different public
components. For instance, How do you apply arguments a) and b) when the
issuer is a PCA and the user a CA?
The tremendous advantage of naming hierarchy is that of 2) (in the sense
that in non-hierarchical infrastructures, it is possible to validate the
same user through multiple certification paths), but at PCA level you do
not have it. The point is: How can a user keep explicitly sure that one
certificate can not be traced to more than one PCA in an easy way (like
with naming subordination)? She/he can't.
Because examples is the best way to get understanding, suppose the
following scenario:
ES | | US
| Low High |
| |
UPC GTE
/ \ |
COM CS |
/ \ |
Alicia Francisco Bob
Low and High are PCAs for different levels of assurance. GTE is a
commercial company, UPC is a university that has two different sections,
the educational Computer Science Department (CS) and the COMmercial and
Administrative Department (COM).
In this example, GTE has high assurance level, so is certified under PCA
High. UPC has a high secure system to protect COM, so UPC wants to be
endorsed by PCA High. But, UPC also wants to certify educational and
research staff, however, educational user's security is considered low,
so UPC wants to express this fact by issuing CS in a low policy.
Summarizing, GTE is under High, and UPC is under High and Low policies.
You may or may not assume that COM and CS are other UPC subordinated
CAs.
Suppose that the high secure systems in UPC are based on a magnetic card
that can only hold a private key component. Or suppose that the security
administrators do not want to worry in protecting several keys. Or, etc.
Question: Is UPC security affected by the fact of having only one key
pair for different assurance levels? (I think NO)
Question: Is Bob in GTE concerned by this fact? (I think that Bob
uniquely wants to unambiguously ascertain that Francisco is working in a
low assurance level and Alicia in a high one)
Suppose now that CS in UPC has obtained a contract to develop security
technology together with GTE. One of the requirements is that some users
of CS work in a high assurance environment. So, in particular, Francisco
is issued under High policy, but preserving the Low assurance level as
well. In this way, UPC makes the minimum investment to get such High
assurance before issuing any certificate.
Question: If CS is a low assurance CA subordinated to UPC, will you
secure CS in a high level to accomplish Fransciso's name subordination
only? Or, on the contrary, will you allow UPC to sign Francisco's High
assurance certificate irrespective of CS CA? (I think the latter)
Question: Has Francisco to change his name? (I think NO).
Suppose that Francisco has to remotely access GTE systems in order to
securely login/transfer files. For security reasons, GTE only grants
such kind of access to users certified under GTE, i.e. login and ftp
daemons only know (trust) GTE public component.
Question: Will Francisco necessarily be issued with subject name under
GTE? (I think NO).
Question: Will Francisco need to use a new key pair? (I think NO).
Question: What will a third user interpret when validating a certificate
with subject "GTE, Francisco"? (I think, "Francisco is an employee from
GTE").
Supposing GTE issues a certificate with Francisco's UPC name as subject.
Question: Will Francisco need to use a new key pair? (I think NO).
Question: Will access control work? (I think YES)
Question: After successful High assurance validation, will a third user
(for instance Bob) suspect that Francisco's certificate has been
maliciously issued because there is not issuer-subject subordination? (I
think NO).
My **CONCLUSIONS** beneath these questions are:
If you are worried because company A may issue a certificate to an
employee of company B, why are you not worried in that a high assurance
PCA can certify a low assurance CA (as Rhys noted), or that several PCAs
can sign the same key pair of a CA?
Where is the threat if GTE issue a certificate with subject
"UPC,Francisco" without Francisco's permission? Can anybody take profit
of this certificate? They are _issuer CAs and policies_ which develop
trust, not users, aren't?.
Do you really think that a certificate with issuer "ES,UPC" and subject
"US,GTE" will be accepted for anybody but users below UPC?
It should be very easy to instruct a UA to warn users because this kind
of cross-naming. If you are a user from UPC, you will probably trust it;
but if you are a user from other organization, you will probably
question this certificate.
Anyway, I want to think that CAs will normally have good codes of
practice (like PCAs have, haven't?), on the contrary malicious CAs can
do almost anything. But note that any subverted action has to be
endorsed, therefore it is traceable.
This is because my proposal put explicit certification information in
the certificate unique identifier, but not in names. This information
give you evidence of the cert hierarchy, i.e. top-level, policy and
subsequent CAs, thus uniquely identifying a certificate in the overall
hierarchy while leaving names to be administered by _Naming_ Authorities
not _Certification_ Authorities. Moreover, with this method, there is no
place for ambiguities in certification paths, like the ones described in
the example above.
I now like Bob posture (although his successive changes):
I am beginning to be persuaded that name subordination should be a
_PCA policy requirement_ for user certification, and a_ user
option_ for validation.
I will probably extend this to CAs as well. They should be end users who
finally decide what to trust. Perhaps nearly all users will instruct
their UAs to accept certificates with names subordinated only, but
perhaps there will be others that need not such a subordination. If you
impose that limit, you loose those users.
I particularly think that all your proposals (Bob, Warwick and Rhys) are
in the line of authoritative attributes that may very well fit in an
extended certificate. However, certification information to uniquely and
unambiguously identify certificates is explicitly addressed by X.509
(93) recommendation to be included in the certificate.
This give me the chance to comment a previous message from Bob (Subject:
Re: Changes to X.509 certificate format):
While I'm on this subject, Richard Ankney made two observations:
1. X9.30 originally used the UID to distinguish between multiple
certificates for a user, but the UID is used by the 1993 X.500 ACL
mechanism so it has to identify a user, not his certs. We
regretfully removed this idea from X9.30.
I'm not sure that I understand this, perhaps because I haven't looked
at strong authentication all that seriously yet. Since you are running
a DSA with strong authentication, could you comment?
I do not know which is exactly Richard Ankney current position, but his
comment was not completely exact.
In a X.509 (93) certificate, it is the <issuerDN+issuerUniqueId+SN> what
distinguishes between multiple certificates for a user. And it is the
<subjectDN+subjectUniqueId> what distinguishes reassigned instances of a
user and what is used by X.500 (93) ACL mechanism.
So, I don't think he has to remove this idea from ANSI X9.30.
If one user (DN) has multiple certificates for different purposes, how
are we supposed to tell the difference? One obvious way is to create
another entry under the user's common name node, but now I've lost
the sense of a single user??
Certainly, by the issuer DN. A certificate has never been identified by
means of the subject DN. You identify a X.509 (88) certificate by means
of the "issuerDN+SN" and now, if you use X.509 (93), you uniquely
identify a certificate with "issuerDN+issuerUniqueId+SN".
Francisco Jordan
Group of Distributed Systems
UPC - Universitat Politecnica de Catalunya
Barcelona - Spain