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
frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com Fax. (613) 723-5078
-----Original Message-----
From: Ari Kermaier [mailto:arik@phaos.com]
Sent: Wednesday, December 06, 2000 3:40 PM
To: ietf-pkix@imc.org
Subject: CRMF EncryptedValue
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