Subject: Re: PKIX Roadmap

From: Stefan Santesson <[email-masked]>
Date: Mon, 21 Sep 1998 16:19:49 +0200

Al,

I finally got time to look a little bit deeper into the roadmap document.
I think it is very well formed but I have some minor disagreements.

1) Concerning definition and use of the term Root CA
2) Result from CA compromise
3) Use of certificates.

1 - Root CA
---------
Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives
the impression that Root CA is at the top of some hierarchy. 

This does not seem to harmonize with the definition of root CA in
"Certificate Management Protocols"

  "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."

So in fact every CA in a domain is likely to be "root" for some of its
subscribers.
I personally prefer the rem "Top CA" when describing a hierarchy.

2 - CA compromise
------------------
In section 3.4.5 it is said that compromise of a root CA is always
catastrophic and that the entire infrastructure subordinate to that root CA
has to be dismantled and started over again. This gives the impression that
a subordinate CA has to be dismatled.

My comment is that 
a) Since the rootCA does not denote any hierarchy we can't define which CA
that is subordinate or not to a specific root CA
b) A compromised CA does only require that particular CA to be dismantled.
No other non-compromised CA has to be dismantled. Other CA:s has to revoke
cross certificates to th compromised CA and all subscribers using the
compromised CA as root CA, are totally cut off until they get another
rootCA key, but that's another aspect.

3 - Certificate usage
---------------------
Section 3.1 states that:
"Certificates is used in the process of validating signed data."
This definition is leaving out any use for the purpose of encryption. I.e.
data encryption, key agreement and key exchange.

Regards
/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Al Arsenault <[email-masked]>
Date: Mon, 21 Sep 1998 13:32:57 -0400

Stefan,

	Thanks for your comments.  Responses in line (Sean can make changes to the
draft as appropriate).

>I personally prefer the rem "Top CA" when describing a hierarchy.

You are correct; I was using the term "rootCA" to indicate the top of a
hierarchy (possibly, a hierarchy of depth one - two counting the end
entity).  That is inconsistent with CMP.  We'll have to resolve that.  I
personally prefer using the term "rootCA" to mean the top of a hierarchy,
and "trust anchor" to mean the CA that the end-entity directly trusts.  But
we'll figure out something - "topCA" is probably feasible for now.

>2 - CA compromise

Your comment (a) is correct, given the different meaning of "rootCA" that I
didn't catch earlier.  However, I disagree with part of your comment (b).
That to me goes to the heart of a "CA Certificate" vs. a
"Cross-certificate".  

Suppose that CA2 has no self-signed certificates (it might have a
self-issued certificate for key management, but that's not relevant at this
point). CA2's CA certificate is issued and signed by CA1.  Thus, CA2 is
subordinate to CA1.  Now, if CA1's private key is compromised, then CA2
must be "dismantled".  That is, there is no reliable way for an outside
entity to know whether CA2's cert was legitimately issued prior to the
compromise of CA1's key, or whether CA2's cert was signed by the malicious
party now holding the copy of CA1's private key.  The only thing you can do
is kill CA2 and start over with a new cert issued by the new, re-installed
CA1.  (Not to mention the mechanical problem of constructing a valid cert
path going through CA2 to the valid CA1:-). Of course, "dismantling" is a
strong word; you'd have to rebuild CA1 with a new key, and sign a new
certificate for CA2 using the new, un-compromised key.  You wouldn't
necessarily need to erase CA2's database, train new people, buy a new
hardware platform, etc. :-)

With a cross-certificate, as you point out, there's no need to do anything
over than revoke the cross-cert CA2 has issued for CA1 (if there is one).

>3 - Certificate usage

Agreed.

				Al Arsenault

- the above opinions are my own.  They may or may not reflect the opinions
of my employer or of any other organization with which I have a relationship.