Re: PKIX Roadmap

[Al Arsenault <aarsenault@xxxxxxxxxx>]

Stefan,

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


At 04:19 PM 9/21/98 +0200, Stefan Santesson wrote:
>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.
>

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

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

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.