Subject: RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field

From: [email-masked]
Date: Mon, 12 Mar 2001 08:34:44 -0500

Hi Carlisle,

I know we exchanged few Emails on this particular issue in July last year,
but it seems I overlooked the final question in your previous response
below. 

Again I am not sure if I am missing something, but when thinking further
about the wrapping and unwrapping of private keys, I have noted that the
comment for the EncryptedValue under both Section 6.4 and Appendix C of RFC
2511bis still indicates that when the encValue field contains an encrypted
PrivateKeyInfo, the intendedAlg field is unnecessary (since this information
is included in PrivateKeyInfo) and MUST be omitted.  As indicated before,
the information included in PrivateKeyInfo once through the PKCS #11
C_WrapKey function is all encrypted.  This means that any information about
the intended algorithm for the private key is no longer available until the
PrivateKeyInfo is decrypted (i.e. unwrapped).

In response to your previous question, the C_UnwrapKey function from Section
11.14 of PKCS #11 does everything in one call and consequently all the
necessary information it requires needs to be known at priori.  However, the
problem in this case is that the C_UnwrapKey needs to know the template for
the private key (i.e. the type of the private key) that will be unwrapped as
part of its syntax.  The only source for this particular information would
seem to be the EncryptedValue intendedAlg field since the PrivateKeyInfo
privateKeyAlgorithm field is still encrypted.

Since the intendedAlg field MUST already be present when encValue contains
some other format/encoding for the private key, I would suggest changing the
intendedAlg field from OPTIONAL to mandatory for all cases or to indicate
that it MUST also be present when the encValue field contains an encrypted
PrivateKeyInfo.

Does this seem appropriate?

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078 

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Monday, July 17, 2000 14:54
To: [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: Re: CRMF encValue Field

Hi Francois,

[snip]

> 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?
 
No, this approach doesn't strike me as particularly better.  It seems like a
real kludge to include an AlgId for the same thing twice, but to specify (in
commentary) that the parameters should be NULL for one of these and non-NULL
(i.e., present) for the other.  This reduces clarity for the
reader/implementer and may run in to trouble with some compilers that are
expecting actual parameter values.

As for fact that the AlgId in PrivateKeyInfo is encrypted, why is this a
concern?  Does the receiver need to know this prior to decryption?

Carlisle.

---

From: Carlisle Adams <[email-masked]>
Date: Mon, 12 Mar 2001 09:55:44 -0500

Hi Francois,

> ----------
> From:
> [email-masked][SMTP:[email-masked]]
> Sent: 	Monday, March 12, 2001 8:34 AM
> To: 	[email-masked]
> Subject: 	RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field
> 
> Hi Carlisle,
> 
 
I have no problem with this as long as the implementors have no objections.
I can change the text to something like "The intendedAlg field MUST be
present unless this information is known a priori to both sender and
receiver by some other means."

Does this raise concerns for anyone?

Carlisle.