[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PKIX Roadmap
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 <stefan@accurata.se>
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
-------------------------------------------------------------------