Subject: RE: Re: CRMF encValue Field

From: [email-masked]
Date: Mon, 17 Jul 2000 11:55:53 -0400

Hi Stephen,

I have noted that the recently published July version of RFC2510bis now
contains a note in Appendix D on "RFC 2511 Clarifications" about this
particular issue, however an exception was added for the Diffie-Hellman
algorithm OID and parameters whereas those defined in Appendix B2 of this
specification (i.e. RFC2510bis) MUST be used instead of the OID and
parameters defined in PKCS#11. Although I understand that this exception was
necessary since PKCS#11 currently only supports the PKCS#3 flavour of
Diffie-Hellman whereas Appendix B2 of RFC2510bis is about the ANSI X9.42
flavour of Diffie-Hellman, this should have been mentioned in this
clarification.

In addition, this same clarification indicates that in this case, the
intendedAlg field is unnecessary (since this information is included in
PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier field
within the PrivateKeyInfo is encrypted, which means that the
"EncryptedValue" type would not contain any information in the clear about
the OID of the private key that it is carrying. Was this your intend, please
clarify? I also understand that including the intendedAlg field would
duplicate the occurrence of the parameters field, since the syntax of the
"AlgorithmIdentifier" type also contains a "parameters" field, however by
still indicating the algorithm OID, but forcing the "parameters" field
within the intendedAlg field to be NULL would allow the "EncryptedValue"
type to indicate what is the OID of the private key that it is carrying, but
not duplicate the parameters field. Wouldn't this approach be better?

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: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, June 30, 2000 7:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: CRMF encValue Field

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
> 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

-- 
____________________________________________________________
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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Jul 2000 19:05:22 +0100

Hi Francois,

Why don't you propose some changes to the text if you think additional
clarficiation is needed?

Stephen.

(BTW: Your mail broke my brain's long-sentence-parser:-)