Subject: CRMF encValue Field

From: [email-masked]
Date: Thu, 29 Jun 2000 19:27:41 -0400

Steve,

As agreed yesterday at the PKI Forum meeting in Dublin, could you please
check and add some clarification in the next version of RFC2510bis about
what exactly must be encoded in the "encValue" field of the EncryptedValue
structure, which is described in Section 6.4 of CRMF [RFC2511]. This
clarification will become necessary in order to ensure interoperability
between components using hardware or software from different vendors (i.e.
clients, RAs and CAs) that might use this CRMF "encValue" field.

As discussed, please note that hardware cryptographic module vendors that
implement PKCS#11 would normally use the Cryptoki wrapping mechanism to
encrypt any private key that has to be extracted from their module to go in
this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for
wrapping a private key that:

"Cryptoki Version 2.01 allows the use of secret keys for wrapping and
unwrapping RSA private keys, Diffie-Hellman private keys, and DSA private
keys. For wrapping, a private key is BER-encoded according to PKCS #8's
PrivateKeyInfo ASN.1 type."

I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is
currently being encrypted within this CRMF "encValue" field of the
EncryptedValue structure for today CMP implementations.

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Francois Rousseau 
Sent: Thursday, May 25, 2000 3:42 PM
To: 'Carlisle Adams'
Cc: [email-masked]
Subject: Encryption of Private Keys in CRMF and CMP

Carlisle,

In Section 6.4 of RFC 2511 on CRMF, it is indicated that the EncryptedValue
field "encValue" is a BIT STRING, however I could not find any further
detail in RFC 2511 nor in RFC 2510bis, which also use this syntax, about how
to create this encrypted value (restricted, in RFC 2510bis, to be either
private keys or certificates).

Am I missing something?

I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the
symmetric algorithm that was used to encrypt a private key value and that
Appendix B2 of RFC 2510bis mandates that conforming implementations MUST
support 3-DES (3-key-EDE, CBC mode) for this. However, this does not tell me
what exactly is being encrypted.

Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type
"RSAPrivateKey" from Section 11.1.2 of PKCS#1 for a RSA private key since
RFC 2511 EncryptedValue field "intendedAlg" already tell me the intended
algorithm for which the private key will be used for? 

Thanks in advance for any help.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Jun 2000 12:33:47 +0100

Hi Francois,

As I said yesterday, I'll check what the folks on Bob's ca-talk list
have implemented. I do agree that handling pkcs#11 tokens is desirable,
but I would guess is lower priority than not breaking current
implementations. So pkcs#11 support (if different from what's 
implemented already), could either be added to 2510bis as an
implenmentation note, or, if it gets complicated, in a separate 
"pkcs#11 key wrapping in CMP" draft.

Let's wait & see what the developers have done.

Regards,
Stephen.

> [email-masked] wrote:
> 
> Steve,
> 
> As agreed yesterday at the PKI Forum meeting in Dublin, could you please check and add some
> clarification in the next version of RFC2510bis about what exactly must be encoded in the
> "encValue" field of the EncryptedValue structure, which is described in Section 6.4 of CRMF
> [RFC2511]. This clarification will become necessary in order to ensure interoperability between
> components using hardware or software from different vendors (i.e. clients, RAs and CAs) that
> might use this CRMF "encValue" field.
> 
> As discussed, please note that hardware cryptographic module vendors that implement PKCS#11 would
> normally use the Cryptoki wrapping mechanism to encrypt any private key that has to be extracted
> from their module to go in this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for
> "Cryptoki Version 2.01 allows the use of secret keys for wrapping and unwrapping RSA private keys,
> Diffie-Hellman private keys, and DSA private keys. For wrapping, a private key is BER-encoded
> according to PKCS #8's PrivateKeyInfo ASN.1 type."
> 
> I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is currently being
> encrypted within this CRMF "encValue" field of the EncryptedValue structure for today CMP
> implementations.
> 
> Regards,
> 
> Francois
> In Section 6.4 of RFC 2511 on CRMF, it is indicated that the EncryptedValue field "encValue" is a
> BIT STRING, however I could not find any further detail in RFC 2511 nor in RFC 2510bis, which also
> use this syntax, about how to create this encrypted value (restricted, in RFC 2510bis, to be
> either private keys or certificates).
> 
> Am I missing something?
> 
> I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the symmetric algorithm that
> was used to encrypt a private key value and that Appendix B2 of RFC 2510bis mandates that
> conforming implementations MUST support 3-DES (3-key-EDE, CBC mode) for this. However, this does
> not tell me what exactly is being encrypted.
> 
> Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type "RSAPrivateKey" from Section
> 11.1.2 of PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field "intendedAlg" already
> tell me the intended algorithm for which the private key will be used for?
> 

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com