Subject: CRMF EncryptedValue

From: Ari Kermaier <[email-masked]>
Date: Wed, 06 Dec 2000 15:40:18 -0500

It seems to me that the EncryptedValue structure defined in CRMF (used in 
POPOPrivKey and PKIArchiveOptions) may be incompletely specified.

The syntax from draft-ietf-pkix-rfc2511bis-00 Section 6.4 is:

EncryptedValue ::= SEQUENCE {
       intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
       -- the intended algorithm for which the value will be used
       symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
       -- the symmetric algorithm used to encrypt the value
       encSymmKey    [2] BIT STRING           OPTIONAL,
       -- the (encrypted) symmetric key used to encrypt the value
       keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
       -- algorithm used to encrypt the symmetric key
       valueHint     [4] OCTET STRING         OPTIONAL,
       -- a brief description or identifier of the encValue content
       -- (may be meaningful only to the sending entity, and used only
       -- if EncryptedValue might be re-examined by the sending entity
       -- in the future)
         encValue       BIT STRING }

How does the recipient of such a structure know what block padding scheme 
may (or may not) have been used with the symmetric encryption algorithm? 
CMS, for example, specifies mechanisms whereby this information is conveyed 
with similar message structures, but I can't seem to find any mention of 
this in CMP/CRMF. Any ideas, anyone?

Ari

---

From: [email-masked]
Date: Thu, 7 Dec 2000 15:10:12 -0500

Ari,

It is not incomplete if implementations follow the approach described in the
note after the ASN.1 for the EncryptedValue structure in Section 6.4:

-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate, implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.9, with the exception that the D-H algorithm OID and
-- parameters MUST be as defined in ANSI X9.42.  In this case,
-- the intendedAlg field is unnecessary (since this information is 
-- included in PrivateKeyInfo) and MUST be omitted.
-- If encValue contains some other format/encoding for the private 
-- key, intendedAlg MUST be present. Furthermore, the first octet of 
-- valueHint MAY be used to indicate the format/encoding (but note 
-- that the possible values of this octet are not specified at this
-- time).

Section 12.9 of PKCS#11 v2.10 describes precisely how to use 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.  PKCS #8 requires an algorithm identifier for the
type of the private key and the parameters for the algorithm identifiers.
Both of these values are also mentioned in PKCS#11 except for X9.42 as per
the note above.  Once a private key has been BER-encoded as a PrivateKeyInfo
type, the resulting string of bytes is encrypted with the secret key.  This
encryption must be done in CBC mode with PKCS padding.

Cheers,

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: Ari Kermaier [mailto:[email-masked]]
Sent: Wednesday, December 06, 2000 3:40 PM
To: [email-masked]
Subject: CRMF EncryptedValue

Ari