Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY? - msg#00107

Previous Message by Date: click to view message preview

Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

> From: "Anil R. Gangolli" <gangolli@xxxxxxxxxxxxxxxxxx> > > Mark Shuttleworth's second point about separating the CA and the > Key Escrow/Recovery Agent is still a valid and important one. > > The model I have advocated earlier is that there be a standardized > format for a "key escrow receipt". This would be a message effectively > asserting that "the private key associated with public key X has been > escrowed with me and will be kept by me until at least date D, signed > <escrow agent>". That is a fine idea, along the lines of CertCo's impending standardized formats for things like billing information. But it is not clear what Mark wants to eliminate from the protocol in an effort to separate the duties of CA and KR Agent. PKIX-3 section 2.2.1.3, "Location of key generation", says: "In this specification, key generation is regarded as occurring wherever either the public or private component of a key pair first occurs in a PKI message. Note that this does not preclude a centralized key generation service - the actual key pair may have been generated elsewhere and transported to the end entity, RA, or CA." For generation and distribution of classified keying material, we use a centralized facility and a mechanism based entirely on symmetric encryption. We are under intense pressure to integrate the centralized symmetric key distribution system with the decentralized public-key-based infrastructure. But even if we weren't, there would still be advantages to generating keypairs in a highly secure central facility and distributing them to CAs, RAs, and end users. This is totally unrelated to "Key Recovery" for evesdropping purposes, although it does facilitate replacement of a user's lost/destroyed keys - a capability which is a business requirement of any prudent organization. PKIX 3 requires support for key generation at (effectively) the CA, RA, and end entity. This is appropriate in and of itself, for reasons unrelated to third-party Key Recovery. In a commercial setting, I could easily envision a CA with a good hardware random number generator and lots of clients without them. If the CA's policy is "generate the key pair, send them to the client, then destroy everything related to the private key", and the client doesn't trust the CA to follow it's policy, then the client should get another CA. Additional third-party-Key-Recovery-specific functionality such as what you suggest would be good to standardize as an option, but doesn't have to be required for PKIX compliance.

Next Message by Date: click to view message preview

Re: key recovery options for PKIX-3 CAs?

Peter, I have a simple, real answer to your scenario: there are lots of other means by which the user's medical records might have been inappropriately released by the company. Showing that on this release using the SSL mechanism was authorized would only "prove" that the company did not inappropriately release the data in this fashion in this instance. Of course the company will use its records to substabtiate its case, but that is not the whole answer. In a more narrow sense, the critical question should be whether the company could forge its records to support its claim. If not, then presumably the combination of crypto and other controls provides a basis for non-repudiation. If so, then I'll offer to be an expert witness, for a suitable fee :-), against the company. Steve

Previous Message by Thread: click to view message preview

Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

Using today's RSA SSL enrollment infrastructure, this is very simple to achieve as I'm sure you know. User contacts CA, generates key, makes cert request, request is pending. User goes to escrow agent, presents private key over 128bit channel, obtains escrow-issued client-auth cert for said key, with policy extensions constraining its use for presentation to regulated CAs.. User goes to one of nominated CAs and over SSL presents escrow-authority's client-auth cert to signal previous desposit of private key for named public key in client-auth cert. CA has proofs it needs; deposit has occured. Issues cert as normal; software replaces existing escrow-issued temp client-auth cert with CA-issued cert. Key escrow receipt, and acceptance of escrow policy by the subscriber, with all attendent legal stuff, and dates, is the "receipt". This may be actually doable today, if Netscape browsers for example allow the cert chain standing for a user's private key authority to be substituted (under appropriate controls) in the platforms key/cert store. The original cert chain is the receipt; its replaced by the CA chain once issued; receipt is discarded or sent to audit log. ---------- Now, to PKIX: In the brand new PKIX-3 way of doing the same thing, surely all one needs to do is have a split of responsibility. The CA functional groups of PKIX-3 are performed by PKI entities; the same PLUS the key recovery functional group are performed by the organizational or national Key Recovery agent. Policy over forcing CAs to be controlled by escrow policy is then instrumented by regulation/contract governing verification keys used by CAs to validate the key escrow receipt and confirm its operational status, with confirmation being ordained by regulation/contract prior to CA cert issuance. There would seem to be lots of PKIX ways to instrument the unbundling of CAs and key-recovery agents, yet enforce a key-desposit policy prioir to issuance of a cert. The use of signed-receipts obviously allows juridicitional controls to be imposed by the escrow authority - thou shalt only issue names with leading RDN c=US, for example. Apart from altering PKIX-3 language to allow this separation, do we need to standardize anything? Surely all it needs is local management policies to configure such mechanisms together if certs themselves serve as the receipt mechanism. Peter. Anil R. Gangolli wrote: > Mark Shuttleworth's second point about separating the CA and the > Key Escrow/Recovery Agent is still a valid and important one. > > The model I have advocated earlier is that there be a standardized > format for a "key escrow receipt". This would be a message effectively > asserting that "the private key associated with public key X has been > escrowed with me and will be kept by me until at least date D, signed > <escrow agent>". > > A CA or other entity (e.g. RA) may enforce a requirement that > clients present such a receipt from an approved agent (as determined > by its policy) as part of any request for a certificate in which certain > key usage indications are present. (e.g. A CA may require this > to certify key exchange keys but not signing only keys). > > Consider for example a company who wishes to use a CA > administered by an outside agency but wishes to keep > its own keys, or run its own internal recovery > (or generation) service. > > --a. > > -- > Anil R. Gangolli > Structured Arts Consulting Group > mailto:gangolli@xxxxxxxxxxxxxxxxxx > http://www.StructuredArts.com

Next Message by Thread: click to view message preview

Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

> resulting private key. I also provided an example of why one might want to > have a CA generate a key pair for a user, irrespective of key recovery. If you're talking about ensuring good RNG, then surely Java, which runs on the client machine and thus keeps the private key private, is a better answer? Sure, no quantum effect randomness, but one can get pretty good. Even then I wonder at the opportunities for Java apps that generate the key on a client platform and then send a copy elsewhere. > Defining message formats to suppprt key recovery is also a possibility, if > the WG elects to address that issue. There is also a group developing key > recovery standards for a Federal Information Processing Standard, a part of > which will encompass the sort of user - key recovery/registration agent > interaction. So the vendors can adopt that standard. Does the IETF want to endorse key recovery or escrow even tacitly? -- Mark Shuttleworth Thawte Consulting