Subject: RE: Terminology question: "root CA"

From: Al Arsenault <[email-masked]>
Date: Mon, 01 Feb 1999 10:17:02 -0500

Okay, to wrap this up, here's how we're proposing to proceed:

The problem is as follows:  In the scenario outlined before, where T
certifies A, B, and C, which do not have self-signed certificates but are
still CAs; and some relying party deems A to be the point in the PKI which
it trusts "the most",

	RFC 2459 says that T is the root CA and A is the most trusted CA

	CMP says that A is the root CA and T for all practical purposes doesn't exist.

Most of the literature in the field, and most (although certainly not all)
of the comments on this list tend to prefer the CMP terms.  Thus, the
Roadmap will also prefer those terms, although it will point out the
unfortunate difference in terminology between RFC 2459 and
RFC-whatever-number-CMP-winds-up-being.  

As an FYI, the section of the Roadmap where this arises is where we try to
explain:

	- what happens to A when T's key is compromised;

	- what happens to user Fred, who has selected A as the "root of trust",
when A's certificate is revoked by T.

Thanks for the useful input,

				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: Stephen Kent <[email-masked]>
Date: Mon, 1 Feb 1999 15:58:20 -0500

David,

I have to agree with Warwick. Rootedness is in the eye of the beholder,
well, OK, in the cert verfication mechanism of the relying party.  One
man's root may be another man's (or woman's) cross-certified CA. We ought
not let the browser PKI models overshadow more general PKI models.

Steve

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 1 Feb 1999 15:04:51 -0600

Much of the recent conversation concerning the "roadmap" to
PKIX documents seems to be directed not at merely
elucidating what is already specified in less formal
language, but  defining particular ways of thinking about PKI; 
or,  respecifying matters which some parties might
think PKIX-1 consensual agreements did insufficiently well.

Perhaps we should re-resolve that PKIX documents
designed to serve as application-independent
and (Internet) environment-independent frameworks 
should remain that way. One or more policy documents
can take a different tack, to suit communities with
particular  needs for controlling the behaviour of 
subscribers and relying parties alike, as we agreed
in Orlando. The roadmap document is NOT such a policy
document, as far as I can tell, however. Neither  is it 
"generic policy",   or "good practice" or "standard operating 
procedure", or any other form of authoritative guidance
instrument.  It just changes the language form - to assist folk
navigate over the range of existing specified materials.
 
Generally, the notions of fixing management domain constructs, 
mandatory uniform naming architectures, or required delivery
of services for conforming status as  PKIX TTP, all seem as
alien  to the goals of this IETF forum as they did last year
when I last said the same thing (several thousand, unread 
messages ago).

Peter.