Subject: Key Recovery in the CMP

From: Sarbari Gupta <[email-masked]>
Date: Thu, 21 Jan 1999 13:54:00 -0500

I had several comments related to the treatment of key recovery in the
CMP document. I realize that these comments would have applied to the
last version of CMP - however, I did not get a chance to send these out
in time.
Since there appears to be little or no explanation on how a key recovery
request operation is typically performed, I was forced to make my own
assumptions, and base my comments upon those assumptions. The primary
point I would like to make is that the handling of key recovery in the
current CMP document is much too terse, and, depending upon the
assumptions and envisioned scenarios, the message syntax may be
incomplete or even flawed. I personally think that the key recovery
portion of CMP needs to be reworked and expanded. 
My specific comments follow: 
I) In section 3.3.7, under key recovery request message: 
Comment 1: The CMP document says, "For key recovery requests the syntax
used is identical to the initialization request, CertReqMessages." I
would contend that key recovery is dissimilar enough from initial
certification request that it deserve a more targeted message syntax.
For example, the CertReqMessages syntax in CRMF has an optional
ProofOfPossession field that is in inapplicable for key recovery (how
can you prove possession of a private key that you are trying to
recover??) Conversely, the CertReqMessages syntax does not appear to
support a field that will allow the requester to pass authorization
information (such as a passphrase or authentication token) to the CA. I
would recommend that the syntax for a new message, KeyRecoveryReq, be
defined to specifically address the required fields for key recovery. I
would be happy to supply this new syntax if there is agreement on this
issue.  
Comment 2: The sentence "Typically, SubjectPublicKeyInfo and KeyId are
the template fields which may be used to supply a signature public key
for which a certificate is required" has many inconsistencies. First,
key recovery requires key identification, and not templates. Second, why
would I want to supply my signature public key for key recovery instead
of my encryption public key? Third, it says, "a certificate is required"
as the intended goal of key recovery - in actuality, a private key is
required. This sentence should be rewritten to something like: "
Typically, the SubjectPublicKeyInfo and KeyId fields are used to
identify the private key for which recovery is required."
II) In Section 3.3.8, under Key recovery response content: 
The syntax for the response message is specified in CMP as:
  >>KeyRecRepContent ::= SEQUENCE { 
  >>	status PKIStatusInfo, 
  >>	newSigCert [0] Certificate OPTIONAL, 
  >>	caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, 
  >>	keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair
OPTIONAL }

Comment 1: The key recovery request message identifies the single key to
be recovered. Yet, the response message, (surprisingly) returns a new
signature certificate, and a sequence of key pairs. I understand that in
certain implementations of key recovery, the signature key is
automatically regenerated when an encryption key is recovered. However,
either there needs to be extensive explanation on this issue, or the key
recovery response syntax needs to be decoupled from the issuance of new
signature certificates. The current syntax and accompanying explanation
does not hang together.

Comment 2: CertifiedKeyPair syntax contains the (recovered) private key
as an EncryptedValue. Should this be EncryptedKey instead? Assuming that
the private key is encrypted (by the CA) with a symmetric key - how is
that symmetric key transported to the requester? We have to assume that
the requester does not have access to his encryption private key - (why
else would he request key recovery??) - therefore, normal key transfer
mechanisms cannot be used. Possibly, the symmetric encryption key that
is used to encrypt the recovered private key, could have been passed in
through the key recovery request message. However, the CertReqMessages
syntax does not seem to support the passing of a symmetric key to be
used to encrypt a private key returned by the CA. 

Best regards, 

- Sarbari Gupta 

=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
[email-masked]
=================================

---

From: Carlisle Adams <[email-masked]>
Date: Mon, 25 Jan 1999 12:12:39 -0500

Hi Sarbari,

Thank you for your questions/comments.  These may highlight a need for
further clarification or discussion in the document (something from which
virtually any technical specification can always benefit), but I do believe
that the seed explanations are there.

In particular, page 8 provides the underlying assumption of the document
with respect to key recovery:  it is "used when an end entity has 'lost' its
PSE" (Personal Security Environment), for example "as a result of a
forgotten password or a lost key chain file".  In other words, the user no
longer has access to its PSE and thus -- in terms of end entity operation --
is effectively in the same position as a brand new entity trying to get
initiated into the system.  This is why the syntax used is identical to the
initialization request; the end entity effectively needs to re-initialize
(including the out-of-band exchange with the CA/RA to protect the
req/rep/conf messages).  Note, however, that the field for requesting a new
signature certificate is optional.  This accommodates those situations in
which the EE wishes to recover one (or more) decryption private keys without
certifying a new verification public key.  This is one of the reasons that
POP, too, is optional in the request message.  As for a "field in the
request to allow the requester to pass authorization information", this is
what the protectionBits are for; there is no need to pass other pass phrases
or authentication tokens.

In the response message, again the newSigCert is optional to accommodate the
cases in which a new verification certificate is not generated.
Furthermore, the keyPairHist needs to be a sequence for generality (i.e., to
accommodate the cases in which one, and in which more than one, key is
recovered).  The syntax of all the messages in CMP need to be general enough
to meet the needs of certificate management in many different environments;
any particular environment may omit some optional fields, or send only one
element of a sequence, or whatever. 

Again, thank you for your interest.  I hope that this helps to clarify
things somewhat.

Carlisle.

-----Original Message-----
From: Sarbari Gupta [mailto:[email-masked]]
Sent: Thursday, January 21, 1999 2:32 PM
To: PKIX (E-mail)
Subject: Key Recovery in the CMP (RESEND WITH LINE FEEDS)

OPTIONAL }

Best regards, 

- Sarbari Gupta

---

From: Sarbari Gupta <[email-masked]>
Date: Wed, 27 Jan 1999 11:30:12 -0500

Hello Carlisle,

Thanks for your response to the questions I brought up. Yes, your note
did clarify a lot of issues. 

Now, I am more convinced that the CMP document has insufficient
explanation about key recovery to do justice to the topic. I completely
misunderstood the use of the certificate template field in CertRequest
syntax when used for KR; I thought it was to identify the key to be
recovered, but your explanation now tells me it is the template for the
new signature certificate. At the very least, a lot more explanation is
required to establish the relation between KR and new signature key
certification - the relation is definitely not intuitive. 

I do not see the value of coupling key recovery (of decryption keys)
with new signature verification certificate issuance, at least at the
protocol level. At initialization time, when a new user requests a
encryption certificate, that request is separate from the request for a
signature certificate for the same user. In other words, two separate
requests go to the CA: one for encryption key certification, and another
for signature key certification, even though the user needs both
certificates to establish his/her PSE. Why is it, then, that for key
recovery, the protocols in CMP somehow couple decryption key recovery
with OPTIONAL signature key certification. Admittedly, when a user's PSE
is destroyed, they will not only want to recover their encryption key
pair(s), but will also need to obtain a new signature certificate -
however, that can be achieved with two separate requests sent to the CA,
one for KR and one for signature key certification. I would strongly
suggest that the two operations be separated at the CMP syntax level. 

Based upon your explanation, I have a new question. Is there any way to
identify the key I would like to have recovered? What if I don't want my
whole history of decryption keys returned to me, but want a specific
single key? Is that currently possible? 

You write that the "protectionBits" are to be used to pass
authentication information to the CA. In a key recovery request message,
do the "protectionBits" represent authorization information for key
recovery, or does it hold authentication information related to the new
signature key certification request? Or is it both? What if the
authorization information for recovering old keys happens to be
different that the authorization information required to be supplied for
new signature key certification? 

You write: 
"In other words, the user no longer has access to its PSE and thus -- in
terms of end entity operation -- is effectively in the same position as
a brand new entity trying to get initiated into the system."

I don't see the two situations as being equivalent. There are certainly
some commonalties; but I would argue that there are enough differences
to make it unwise to put "CertReqMessages" through double-duty as the
key recovery request syntax. The presence of a large number of OPTIONAL
fields (that make sense for initialization, but are of questionable
value for KR) make the usage of this syntax for key recovery very
non-intuitive. I am sure this can be corrected with detailed
explanations along the same lines as your response to my note. However,
I don't really see the point in trying to avoid defining a more targeted
syntax for KR request. 

Finally, you did not seem to address the following question from my
>used to encrypt a private key returned by the CA. 

Regards, 

- Sarbari

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Monday, January 25, 1999 12:13 PM
To: 'Sarbari Gupta'
Cc: PKIX (E-mail)
Subject: RE: Key Recovery in the CMP

Hi Sarbari,

Thank you for your questions/comments.  These may highlight a need for
further clarification or discussion in the document (something from
which
virtually any technical specification can always benefit), but I do
believe
that the seed explanations are there.

In particular, page 8 provides the underlying assumption of the document
with respect to key recovery:  it is "used when an end entity has 'lost'
its
PSE" (Personal Security Environment), for example "as a result of a
forgotten password or a lost key chain file".  In other words, the user
no
longer has access to its PSE and thus -- in terms of end entity
operation --
is effectively in the same position as a brand new entity trying to get
initiated into the system.  This is why the syntax used is identical to
the
initialization request; the end entity effectively needs to
re-initialize
(including the out-of-band exchange with the CA/RA to protect the
req/rep/conf messages).  Note, however, that the field for requesting a
new
signature certificate is optional.  This accommodates those situations
in
which the EE wishes to recover one (or more) decryption private keys
without
certifying a new verification public key.  This is one of the reasons
that
POP, too, is optional in the request message.  As for a "field in the
request to allow the requester to pass authorization information", this
is
what the protectionBits are for; there is no need to pass other pass
phrases
or authentication tokens.

In the response message, again the newSigCert is optional to accommodate
the
cases in which a new verification certificate is not generated.
Furthermore, the keyPairHist needs to be a sequence for generality
(i.e., to
accommodate the cases in which one, and in which more than one, key is
recovered).  The syntax of all the messages in CMP need to be general
enough
to meet the needs of certificate management in many different
environments;
any particular environment may omit some optional fields, or send only
one
element of a sequence, or whatever. 

Carlisle.

-----Original Message-----
From: Sarbari Gupta [mailto:[email-masked]]
Sent: Thursday, January 21, 1999 2:32 PM
To: PKIX (E-mail)
Subject: Key Recovery in the CMP (RESEND WITH LINE FEEDS)

OPTIONAL }

Best regards, 

- Sarbari Gupta