Subject: Re: PKIX Roadmap

From: Stefan Santesson <[email-masked]>
Date: Tue, 22 Sep 1998 06:25:35 +0200

Al,

Just a short reply to CA disaster (See below).

Thanks for your reply, I still disagree to the disaster part.

CA2 does not have to be dismanteled, since CA 2:s key is intact.
What has to be done is that:
- CA1 is rebuilt with new key
- The compromise of CA1 and its new key has to be communicated with
out-of-band means
- CA1 cross certify CA2 (and other CA:s) using the new key
- New cross certificates to CA1 has to be issued and published by other CA:s.

Now all certificates issued by CA2 before the disaster of CA1 can be used
and trusted.
This since the disaster of CA1 didn't destroy CA2, just the link to CA2
from CA1.

/Stefan

At 01:32 PM 9/21/98 -0400, Al Arsenault wrote:
>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.
>
>
>
>
>
-------------------------------------------------------------------
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: Tue, 22 Sep 1998 08:15:43 -0400

Stefan,

	The more I think about this, the more I realize we agree.  It's the words
that need figuring out. Perhaps the words in the draft roadmap are too
strong; we'll have to think about that.

	First, let me note that when CA1 and CA2 are cross-certified - that is,
have a peer relationship, with neither subordinate to the other - I agree
with you about what happens when CA1's key is compromised.

	Now, let us assume that there is a hierarchical relationship - CA2 is
subordinate to CA1. This means to me that the trust anchor used by end
entities below CA2 is  not CA2 - it's CA1.  When CA1's key is discovered to
be compromised, what you do is:

	1 - communicate out of band the compromise. This means that CA2 and all
entities below it are essentially "out of action" temporarily; since CA1 is
the trust anchor, there's no way to construct a valid cert path

	2 - reconstitute CA1 with a new key;

	3 - get CA2's key to CA1 for certification (most likely through
out-of-band means). Yes, this can still be the same key; since CA2's key
wasn't compromised, it can still be used, and it will make things easier in
that you don't have to go re-signing end-entity certs with a new CA2 key.

Now, you're back in action.  

If you agree that this is right, we can figure out words that say that.
The point I wanted to convey is that the entire PKI is dead in this case
until CA1 is brought up and a new CA2 cert is signed, because you can't
construct a valid path back to a valid trust anchor.

(Of course, if trust anchor's compromised key happens to be on all
end-entity hardware tokens in a form that can't easily be changed, you've
still got a problem, but that's beyond the scope of PKIX :-)

				Al Arsenault