Subject: [KEYPROV] PSKC wrapped key question

From: "James Holland" <[email-masked]>
Date: Tue, 20 Nov 2007 19:17:40 +0100

Hi Ming,

                I am a colleague of Philip Hoyer and I have a question about the mandatory digest of key material within the PSKC document. The latest draft state: -

5.1.1.  Data (OPTIONAL)

   Defines the data attributes of the symmetric key.  Each is a name

   value pair which has both a base64 encoded value and a base 64

   encoded ValueDigest.  The value can be encrypted.  If the container

   has been encrypted the ValueDigest MUST be populated with the digest

   of the unencrypted value.

In our scenario we receive a request from a 3rd party to generate a 3DES key in a HSM. In the request they pass a transport certificate that has their public RSA key. With this public RSA key we wrap the generated key for export to the requesting 3rd party. However, as we never have the generated key in “plain” outside the HSM we cannot generate a digest of the key material it to be put into the PSKC document. The wrapped key is returned from the HSM in the  PSKC#8 format which we return in the document.

So, in this scenario,  a man in the middle attack my intercept the request and return their own wrapped key within the document, as they too have the transport key. What would you recommend as a possible solution to this, if any? 

Also, in the scenario when there has been a key exchange ceremony between the two parties, would this be a valid case for no mandatory digest of the key material, with the wrapped key returned?

Regards,

James Holland

Product Architect - ActivIdentity

Mob: +44 787 6197 626

London Office Tel: +44 207 744 6460
Skype on HYPERLINK "callto://hoggmania/"callto://hoggmania/

P Think before you print

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments.

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.16.1/1140 - Release Date: 19/11/2007 19:05
 
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/keyprov

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 26 Nov 2007 16:16:39 -0800

Hi James,
 
This is a good case that you raised where a target key isn't revealed to
the server with HSM.
 
For your first question, I think that it should rely on client
authentication. The transport certificate in a request isn't sufficient
for this purpose, I think. Anyone would be able to request a key,
including MITM.
 
For the second question, we are actually pending on making a change that
doesn't use the presence of a ValueDigest to indicate "isEncryped". It
isn't natural other than the HSM case you raised. One proposal is to add
an attribute in DataType to indicate whether it is encrypted. We defered
this change in the current version in consideration of possible adoption
of XMLEnc that wouldn't need this change.
 
For PKCS#8 format that your HSM returns, do you mean standard PKCS#1
http://www.w3.org/2001/04/xmlenc#rsa-1_5 wrapped 3DES key data?
Currently encryption algorithm type is anyURI; this should give
sufficient flexibility to specify an algorithm.
 
- Ming

________________________________

	From: James Holland [mailto:[email-masked]] 
	Sent: Tuesday, November 20, 2007 10:18 AM
	To: Pei, Mingliang
	Cc: Philip Hoyer; [email-masked]; [email-masked]
	Subject: PSKC wrapped key question

	Hi Ming,

	                I am a colleague of Philip Hoyer and I have a
question about the mandatory digest of key material within the PSKC
document. The latest draft state: -

	5.1.1.  Data (OPTIONAL)

	   Defines the data attributes of the symmetric key.  Each is a
name

	   value pair which has both a base64 encoded value and a base
64

	   encoded ValueDigest.  The value can be encrypted.  If the
container

	   has been encrypted the ValueDigest MUST be populated with the
digest

	 

	In our scenario we receive a request from a 3rd party to
generate a 3DES key in a HSM. In the request they pass a transport
certificate that has their public RSA key. With this public RSA key we
wrap the generated key for export to the requesting 3rd party. However,
as we never have the generated key in "plain" outside the HSM we cannot
generate a digest of the key material it to be put into the PSKC
document. The wrapped key is returned from the HSM in the  PSKC#8 format
which we return in the document.

	So, in this scenario,  a man in the middle attack my intercept
the request and return their own wrapped key within the document, as
they too have the transport key. What would you recommend as a possible
solution to this, if any? 

	Also, in the scenario when there has been a key exchange
ceremony between the two parties, would this be a valid case for no
mandatory digest of the key material, with the wrapped key returned?

	Regards,

	James Holland

	Mob: +44 787 6197 626

	London Office Tel: +44 207 744 6460
	Skype on callto://hoggmania/ <callto://hoggmania/> 

	P Think before you print

	The information contained in this email message may be
privileged, confidential and protected from disclosure. If you are not
the intended recipient, any dissemination, distribution or copying is
strictly prohibited. If you think that you have received this email
message in error, please notify the sender by reply email and delete the
message and any attachments.

	No virus found in this outgoing message.
	Checked by AVG Free Edition.
	Version: 7.5.503 / Virus Database: 269.16.1/1140 - Release Date:
19/11/2007 19:05