Subject: RE: Re: CRMF encValue Field

From: Carlisle Adams <[email-masked]>
Date: Mon, 17 Jul 2000 14:53:48 -0400

Hi Francois,

> ----------
> From:
> [email-masked][SMTP:[email-masked]]
> Sent: 	Monday, July 17, 2000 11:55 AM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: Re: CRMF encValue Field
> 
> 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.
 
I suppose this could have been mentioned, but it seemed pretty unnecessary.
Wouldn't people naturally expect the OIDs in this field to be consistent
with the OIDs defined in Appendix B2?  I doubt that there's much potential
for confusion here, so extra wording for clarification seems redundant.

> 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: [email-masked]
Date: Tue, 18 Jul 2000 09:37:03 -0400

Hi Carlisle,

I accept your responses, but I have an extra comment. According to ANSI
X9.42, the Diffie-Hellman algorithm OID listed in an Appendix B2 of
RFC2510bis represents the algorithm OID for a Diffie-Hellman public key,
however the algorithm OID in the PrivateKeyInfo as mentioned in PKCS#11
identifies the "private key" algorithm OID. Note that Appendix A3 of ANSI
X9.42 indicates that: 

"the syntax and encoding of private keys is considered to be implementation
dependent and beyond the scope of this standard. It may, however, be useful
for specific implementations or derivative standards to define a number type
identified by dh-private-key to encode private keys".

Shouldn't the algorithm OID for an ANSI X9.42 Diffie-Hellman private key be
added to Appendix B2 for this case?

Regards,

Francois

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

Hi Francois,

 

Carlisle.

---

From: Carlisle Adams <[email-masked]>
Date: Wed, 19 Jul 2000 10:45:56 -0400

Hi Francois,

> Sent: 	Tuesday, July 18, 2000 9:37 AM
> To: 	[email-masked]
> "the syntax and encoding of private keys is considered to be
> implementation dependent and beyond the scope of this standard. It may,
> however, be useful for specific implementations or derivative standards to
> define a number type identified by dh-private-key to encode private keys".
> 
> Shouldn't the algorithm OID for an ANSI X9.42 Diffie-Hellman private key
> be added to Appendix B2 for this case? 
 
Technically, you are correct and this is a valid observation.  However, my
feeling is that we do not need to go to the trouble of getting another OID
for this.

If the protocol message included a generic blob then, by all means, we would
need some sort of indicator (i.e., an OID) to say whether the blob contained
a wrapped D-H public key or a wrapped D-H private key.  This is not the
situation here.  We've got a container whose explicit purpose is to carry a
wrapped private key; all we need to do is indicate whether it is a private
key for the RSA algorithm, the D-H algorithm, the DSA algorithm, etc..
Therefore, in this context, the AlgId specifies a particular public-key
*algorithm* (as opposed to a particular public key), and it is clear from
the syntax that what is wrapped is a private key that pertains to this
algorithm.

Perhaps this stretches the exact wording of PKCS #11 and X9.42 slightly, but
I really think there's no possibility of any confusion here, so a new OID is
unnecessary.  Let me know if you disagree.

By the way, thank you, as always, for your careful reading.  You continue to
be very helpful in making sure that various specifications are as clear and
precise as possible.

Carlisle.