Subject: Terminology question: "root CA"

From: Al Arsenault <[email-masked]>
Date: Wed, 27 Jan 1999 14:13:43 -0500

Okay, time to resolve a conflict in terminology:

PKIX-1, the Cert & CRL profile,  implicitly uses "root CA" to indicate the
CA at the top of a hierarchy (see Section 6, "Certificate Path
Validation").  CMP, on the other hand, explicitly states:

	" We use the term "root CA" to indicate a CA that is directly trusted by
an end entity; that is, securely acquiring the value of a root CA public
key requires some out-of-band step(s). This term is not meant to imply that
a root CA is necessarily at the top of any hierarchy, simply that the CA in
question is trusted directly."  (See section 1.2.2, "Certification Authority".)

In the original draft of the Roadmap, we used the term 'root CA' to
indicate the top of a hierarchy - possibly, a hierarchy of one CA.  It was
pointed out that this was inconsistent with CMP.  So - what do we do to fix
it in the next draft, especially given the apparent conflict between the
two soon-to-be RFC's pointed out above?

My personal preference is to point out the conflict somewhere in the
Roadmap, and to use "root CA" to indicate the top of a hierarchy, and
"trust anchor" to indicate the node that is trusted directly.  I'm
soliciting other suggestions, though.

Thanks for any inputs,

			Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.

---

From: [email-masked] (Arnoud "Galactus" Engelfriet)
Date: Wed, 27 Jan 1999 22:26:54 +0100

In article <[email-masked]>,
> soliciting other suggestions, though.

Would using the term "top-level CA" for the hierarchy's top not
be more clear? Then "root CA" can still be used for the starting
point in a chain of trust.

Greetings,

Arnoud

-- 
\/  Arnoud "Galactus" Engelfriet - [email-masked]              This space
    5th year Business & Computing Science student                 left blank
    URL: http://www.stack.nl/~galactus/  PGP: 0x416A1A35      intentionally.

---

From: "Robert W. Shirey" <[email-masked]>
Date: Wed, 27 Jan 1999 15:59:13 -0500

>soliciting other suggestions, though.

Al,

It would be better not to uproot (smile) either meaning from the base
word "root". Instead, we should define a root (smile) meaning for
"root" and then distinguish among the various branch meanings by
attaching appropriate adjectives. This approach has the advantage that
it can be used as the foundation, basis, footing--oh, heck; root--for a
third, fourth, etc. term that also wants to be rooted in "root"; you
don't want to have to stretch for more and more new near-synonyms like
"anchor", do you? So . . .

 - First, use "root" to refer to a public key certificate--or the
public key it contains, or the subject (possibly but not necessarily, a
CA) to which the key is bound--upon which some set of "certificate
users" (sometimes called "relying parties") base their trust in
cryptographic operations involving the public key. This covers both of
your cases and some others, too.

 - Then, replace the terms you propose with "certification hierarchy
root" ("hiearchy root" for short) and "certification path root" ("path
root" for short). (Of course, terms that incorporate root but don't
incorporate my proposed base meaning, should be replaced by something
else; an example is the old MISSI "root".)

By the way, my master listing currently has the following, which would
have to be revised: 

<bold><fontfamily><param>Times_New_Roman</param><bigger>root  

</bigger></fontfamily></bold><fontfamily><param>Times_New_Roman</param><bigger>(R)
<bold>General PKI usage: </bold>The <underline>certification
authority</underline> that is the highest level (most-trusted) CA in a
<underline>certification hierarchy</underline>; that is, the authority
upon whose <underline>public key</underline> all <underline>certificate
users</underline> base their trust.

(C) A root <underline>issue</underline>s <underline>public-key
certificates</underline> to one or more additional CAs that form the
second highest level. Each of these CAs may issue certificates to more
CAs at the third highest level, and so on. To initialize operation of a
hierarchical <underline>PKI</underline>, the root's initial
<underline>public key</underline> must be securely distributed to all
<underline>certificate users</underline> in a way that does not depend
on the PKI's certification relationships. The
<underline>root's</underline> <underline>public key</underline> may be
distributed simply as a numerical value, but typically is distributed
in a <underline>self-signed certificate</underline> in which the root
is the <underline>subject</underline>. The root's certificate is signed
by the root itself because there is no higher authority in a
certification hierarchy. The root's certificate is then the first
certificate in every <underline>certification path</underline>.

(S) <bold>MISSI usage:</bold> A name previously used for a
<underline>MISSI</underline> <underline>Policy Creation
Authority</underline>, which is <bold>NOT</bold> a
<underline>root</underline> as defined above for general usage, but is
a CA at the second level of the MISSI hierarchy, immediately
subordinate to a MISSI root called a <underline>Policy Approving
Authority</underline>.

(S) <bold>PKIX usage:</bold> A CA whose certificate is self-signed;
that is, the issuer and subject are the same entity.

(S) <bold>UNIX usage:</bold> A system user account (also called
"superuser") that has all <underline>privileges</underline> (including
all <underline>security</underline>-related privileges) and thus can
manage the system and its other user accounts.

<bold>root certificate  

</bold>(R) The <underline>self-signed</underline> <underline>public-key
certificate</underline> at the top of a <underline>certification
hierarchy</underline>. (Also see <underline>root</underline>.)

</bigger></fontfamily>Finally, please note that this sort of rooting
around in terminology points out  the lack of a comprehensive and
internally consistent set of crisp, clean, clear definitions is the
root of much misunderstanding in the PKI arena. We need to do more than
just dig into this embedded problem one tuber--I mean, term--at a time,
as we have done with "root" and with "verify vs. validate".

Regards, -Rob-

[email-masked], Phone 703-284-4641, Reception 284-4600, Fax 284-2766

Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200 

1300 North Seventeenth Street, Arlington, Virginia   22209-3801   USA

-

---

From: Brian Korver <[email-masked]>
Date: Wed, 27 Jan 1999 13:49:44 -0800

Al,

I think I prefer "root" for any trusted node in the hierarchy--that such a
node is directly trusted makes it a root, at least from a local
perspective.

---

From: Bill Burr <[email-masked]>
Date: Wed, 27 Jan 1999 17:29:26 -0500

Folks,

I like Al's suggestion for "root" and "trust anchor."  I think that the
term "root" has a pretty well understood meaning in any tree graph, that
is much older and more broadly understood broader than its use in PKI,
and I would like to honor this meaning.  So I would prefer to reserve the
term root for the top node in a hierarchy (tree).  And I would use trust
anchor for any "trusted" CA that has a self-signed certificate and starts
a certification path, which includes all root CAs.

Having said that, the botanist in me says that more appropriate names
would not be root and leaf, but trunk and leaf, since roots themselves
are not singular points, but a tree structure.

Regards,

Bill Burr 

At 03:59 PM 1/27/99 -0500, Robert W. Shirey wrote:

Al,

It would be better not to uproot (smile) either meaning from the base
word "root". Instead, we should define a root (smile) meaning for "root"
and then distinguish among the various branch meanings by attaching
appropriate adjectives. This approach has the advantage that it can be
used as the foundation, basis, footing--oh, heck; root--for a third,
fourth, etc. term that also wants to be rooted in "root"; you don't want
to have to stretch for more and more new near-synonyms like "anchor", do
you? So . . .

 - First, use "root" to refer to a public key certificate--or the public
key it contains, or the subject (possibly but not necessarily, a CA) to
which the key is bound--upon which some set of "certificate users"
(sometimes called "relying parties") base their trust in cryptographic
operations involving the public key. This covers both of your cases and
some others, too.

(C) A root <underline>issue</underline>s <underline>public-key
certificates</underline> to one or more additional CAs that form the
second highest level. Each of these CAs may issue certificates to more
CAs at the third highest level, and so on. To initialize operation of a
hierarchical <underline>PKI</underline>, the root's initial
<underline>public key</underline> must be securely distributed to all
<underline>certificate users</underline> in a way that does not depend on
the PKI's certification relationships. The <underline>root's</underline>
<underline>public key</underline> may be distributed simply as a
numerical value, but typically is distributed in a <underline>self-signed
certificate</underline> in which the root is the
<underline>subject</underline>. The root's certificate is signed by the
root itself because there is no higher authority in a certification
hierarchy. The root's certificate is then the first certificate in every
<underline>certification path</underline>.

(S) <bold>MISSI usage:</bold> A name previously used for a
<underline>MISSI</underline> <underline>Policy Creation
Authority</underline>, which is <bold>NOT</bold> a
<underline>root</underline> as defined above for general usage, but is a
CA at the second level of the MISSI hierarchy, immediately subordinate to
a MISSI root called a <underline>Policy Approving 
Authority</underline>.

(S) <bold>PKIX usage:</bold> A CA whose certificate is self-signed; that
is, the issuer and subject are the same entity.

<bold>root certificate  

</bigger></fontfamily>Finally, please note that this sort of rooting
around in terminology points out  the lack of a comprehensive and
internally consistent set of crisp, clean, clear definitions is the root
of much misunderstanding in the PKI arena. We need to do more than just
dig into this embedded problem one tuber--I mean, term--at a time, as we
have done with "root" and with "verify vs. validate".

Regards, -Rob-

-

</excerpt><<<<<<<<

---

From: Juergen Walter <[email-masked]>
Date: Thu, 28 Jan 1999 14:21:38 +0100

Al, Arnoud, Bill, Brian, all

Firstly, I try to recognize what are the requirements according to a
PKIX terminology.
These are - in my opinion - the following

1) The definition of root-CA shall applicable for both hierarchical and
non-hierarchical PKIs.

2) The root-CA shall issue a self-signed certificate called root
certificate.

3) The root-CA shall appear at the end point of a certificate path that
is constructed by applying the validation algorithm. The end point of
the certificate path shall coincide with the directly trusted CA of the
verifying entity. 

4) The root-CA is free to being cross-certified by another CA or
root-CA.

Are there other and/or additional suggestions?

The terminology root-CA may be interpreted in the way, that a root-CA is
the root of a certificate path. This is always true (i. e. in
hierarchical and non-hierarchical PKIs). Both certification paths and
root-CAs may not uniquely determined. Nevertheless, the root-CA is in
all cases the root in the tpological sense, i. e. the root of a
certification path, which is the subgraph of the whole PKI graph. But
the topology of the whole PKI graph is beyond the scope of PKIX
specification as far as interoperability is concerned.

I agree with Brian and Arnoud.

[Brian] " I think I prefer "root" for any trusted node in the
hierarchy--that such a
node is directly trusted makes it a root, at least from a local
perspective."

[Arnoud] "Would using the term "top-level CA" for the hierarchy's top
not
be more clear? Then "root CA" can still be used for the starting
point in a chain of trust." 

The CMP terminology is my personal preference, because it focuses on
functional description. I think that the roadmap document should use the
terminology as in CMP stated.

According to PKIX-1 one may remain things unchanged at the moment. "at
the top of hierarchy" may be interpreted as "at the top of certificate
path". In addition the roadmap document may give guidance. Further work
should incorporate non-hierarchical models and the CMP terminology.

If there is a general description of trust models (i. e. hierarchical
vs. non-hierarchical) needed, I prefer the terminology of a top-level
CA. The top-level CA is then a root-CA which root-key has not been
certified by any other CA. But this is predominantly an informational
chapter of PKIX drafts.

Let us consider hierarchically designed certification domains which are
cross-certified. What is the top-level CA in this case? I´m afraid we
arrive at the term "n-th top level CA" and only formal algebra may helps
to survive the further PKIX standardization work.

By the way, the CMP terminology fits very well, when one compares the
model with a real-world tree as mentioned by Bill. The leaves of a tree
needs the roots for ingestion whilst the entity needs the root-CA for
trust. There may be more than one root/root-CA and more than one
capillary/certificate path to the root/root-CA. The chosen root-CA may
depend on the entity and his function (i. e. end-entity, relying party,
RA, CA). I am not sure whether the last observation has a botanic
analogy or not.

> opinions of my employer, or of any other organization with which I have a

Juergen

---

From: Al Arsenault <[email-masked]>
Date: Thu, 28 Jan 1999 09:04:19 -0500

Folks,

	Okay, let me try to clarify with a scenario:

Suppose that a company establishes a PKI as a simple hierarchy, with a CA,
T, at the top having a self-signed certificate; and three subordinate CAs,
A, B, and C, underneath. A, B, and C each have certificates issued by T;
they do not have self-signed certificates.  Suppose further that in
furtherance of a business relationship, A cross-certifies with W, a CA
somewhere else in the world but not in this company's hierarchy.  Now,
there's a user, call him Fred, who gets a certificate from A.  Either by
company policy or by personal choice, Fred chooses A -which issued his
certificate - as his "trust anchor" or "root of trust" or whatever.  That
is, it is A's public key that Fred acquires via secure means, and Fred
accepts as valid certificate paths that end with A's certificate.

(Note that this type of arrangement is explicitly supported by PKIX.  That
is, there is no requirement that a "most-trusted CA" or "root of a
certificate path" or whatever we call it have a self-signed certificate.
See Section 6 of the Profile document, PKIX-1, for an explanation.  That
section notes that cert path validation is easier if this "most-trusted CA"
has a self-signed cert, but it doesn't have to.)

	In this situation,  PKIX-1 refers to T (from Fred's point of view) as the
"root CA" and A as the "most-trusted CA".  On the other hand, CMP (also
from Fred's point of view) refers to A as the "root CA" and doesn't refer
to T at all.

	In the roadmap, I'm trying to write a paragraph that addresses what
happens - particularly to A - if T's key is compromised.  Here's the
problem:  how do I refer to T?   Do I use PKIX-1 terms and call T the 'root
CA' (that's my choice) and A the 'most trusted CA' or 'trust anchor'?  Or,
do I use CMP terms and call A the "root CA" and make up some other term for T?

	No matter which I do, some reviewer will correctly comment that I'm being
inconsistent with an RFC that's a Proposed Standard.  So, I'm trying to get
some resolution now.

	My personal choice is, as I've stated, to say that a CA at the top of a
hierarchy - which must have a self-signed cert, by virtue of being the
"top" - be called a "root CA".  As Bill Burr pointed out, this is more
consistent with graph-theory notation than the CMP wording.  Note that it
is perfectly legitimate to have a degenerate hierarchy, which consists of
exactly one CA with a self-signed cert, and some users below it.  This
degenerate hierarchy can then be cross-certified in peer-to-peer
relationships with other such degenerate hierarchies (or even with other,
non-degenerate hierarchies, as described above).  All of the graph-theory
results still hold.

	Then, we need a term for what CMP calls a "root CA".  PKIX-1 calls it a
"most-trusted CA"; I can live with that, but prefer the term "trust anchor". 

	Alternatively, if we're going go with CMP terminology, and a "root CA"
need not have a self-signed cert, then we need a term for that which does
have a self-signed cert and is above the root in a hierarchy, as described
above.

				Al Arsenault

(PS - sorry for the inside joke, but -- the first wise person who suggests
"root registry" is gonna get the electronic equivalent of a punch in the
nose, real quick! :-)

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Jan 1999 17:30:27 +0100

Juergen,

Your statements sound quite reasonable. I have however a minor (?) comment.

> 2) The root-CA shall issue a self-signed certificate called root

It may issue more than one, which will then contain either different security policies
and/or different naming constraints.

Denis

---

From: Juergen Walter <[email-masked]>
Date: Thu, 28 Jan 1999 19:11:01 +0100

Al,

> has a self-signed cert, but it doesn't have to.)

Thanks for pointing that out. My preference is that any "most-trusted
CA" has (at least?) one self-signed certificate, but it doesn´t have to.
So, I have to read more carefully next time.

> happens - particularly to A - if T's key is compromised.

It seems to be difficult. It depends on PKI design. I assume that A´s
certificate issued by T is revoked after T´s key compromise has
appeared. Some issues:

1) Formally, Fred has to accept all certificate paths with endpoint A
even if A´s certificate is revoked. Hopefully, there isn´t any
subliminal trust in T, i. e. A is Fred´s "most-trusted CA" why A has a
valid certificate issued by T. But this seems to be the case in your
example.

2) Hopefully, the designer of this PKI provides all relevant
information, usually contained in a self-signed certificate, in Fred´s
certificate issued by A or equivalent in a valid certificate path that
ends in A.

3) Hopefully, T does not sign the A´s CRL on the behalf of A and the CRL
signing key is not affected by T´s key compromise. 

4) ... to be continued 
 
[PKIX-1] says
The "most-trusted CA" is a matter of policy: it could be a root CA in
   a hierarchical PKI; the CA that issued the verifier's own
   certificate(s); or any other CA in a network PKI.  The path valida-
   tion procedure is the same regardless of the choice of "most-trusted
   CA." [PKIX-1]

I prefer the interpretation that the term "most-trusted CA" is an
operational issue according to the path validation software. That means,
when Fred validates a certificate, he does not check A´s certificate
issued by T. Furthermore, the term "most-trusted" does not influence the
certificate management, especially the revocation management.

Probably, I´ve overseen some facts. But I believe that analysis of your
example is far from being evidently. So, the more interesting fact is
this analysis and, I apologize, not the terminology of T.

>  Here's the

Probably the best, repeat the description above, add a figure and call
it T :-)

Tomorrow I am out of office. Have a nice weekend.

Juergen

[...]

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 30 Jan 1999 21:34:18 -0000

From:           	Al Arsenault <[email-masked]>
Subject:        	Re: Terminology question:  "root CA"

I much prefer Al's suggestion below rather than Warwicks.

Al's definition of rootCA is absolute - i.e. the root CA is fixed -  
whereas Warwick's is relative and depends upon the perspective of 
the relying party. But the name rootCA does not imply relativity. 
However the term trust anchor or most trusted CA does imply 
relativity since you are automatically led to ask the question 
"trusted by whom" - and the answer is "the relying party" of course. 

David

> "most-trusted CA"; I can live with that, but prefer the term "trust

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 370 957 287
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
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

***************************************************