[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: PKCS#11 review comments for base spec 3.0 WD05 and curr 3.0 WD06
Good points Daniel. I agree with them all. I have one comment on the following item though. 3429: CKM_ECDSA_KEY_PAIR_GEN should be removed from that table since it was removed in line 3491. [DarrenJohnson] I’m all for removing this. I made a similar comment before about removing CKM_ECDSA_KEY_PAIR_GEN,
CKA_ECDSA_PARAMS and CKK_ECDSA as they are deperated and replaced by their _EC_ equivalents. But Tim brought up a good point (I think it was Tim, sorry if i’m putting words in your mouth). If we are going to remove the deprecated values, we should
probably do a full sweep and drop all of the depcreated values from the spec and headers. Given the focus on getting 3.0 out, I didn’t follow up on the topic. Once 3.0 was out, I was considering working on a proposal to cleanup/remove all the deprecated
things. I don’t have a strong opinion on this topic other than that we should probably do 1 of 3 things.
1) do nothing at this time and leave the deprecated values in for now for clean up post v3.0. 2) If we remove CKM_ECDSA_KEY_PAIR_GEN, then we should remove the deprecated values for all the EC relateded content. 3) Do the full sweep suggested previously and remove all depcreated values. Thanks Darren From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Daniel Minder Darren, all, I agree to most of Darren’s comments, and some of the ones in base WD05 are already fixed with my interfaces/function lists proposal. However, in your proposal for paragraph 3534-3537 the use of curveName is equivalent to an OID. Shall we really propagate the use of plain text names? I don’t
know all the specs you cite, but are plain text names always consistently used? We have introduced curveName to allow for easy use of Edwards curves, which don’t have
an OID yet. But IMO and OID is the more interoperable way – and also backwards compatible for older libraries. Therefore, I think we should be in favor of OIDs and also
make clear that curveName was introduced in V3.0 and cannot be used with older libs. [DarrenJohnson] Agreed. I was over zealous. For Edwards and Montgomery, we should promote curveName, but OID should be promoted for all traditional curves. Concerning your comments to lines 8124 and 8136: yes, they are valid. But when looking at the description of other data fields in sections 2.34.2 to 2.34.4, it seems that in one case the counter is even invalid and
in all cases also CK_ SP800_108_DKM_LENGTH and CK_ SP800_108_BYTE_ARRAY are optional – but they don’t have it in their name. So, for consistency I would even recommend to remove the “optional” from CK_ SP800_108_OPTIONAL_COUNTER in the whole section 2.34. [DarrenJohnson] Agreed. I think my original intent was to provide clear speratation between the iteration variable and optional counters. But the proposal has since evovled beyond that, and I think
we have that clear sepration now. So removing OPTIONAL make sense to me. Additionally, these are my remarks to the review of Darren: 3429: CKM_ECDSA_KEY_PAIR_GEN should be removed from that table since it was removed in line 3491. [DarrenJohnson] I’m all for removing this. I made a similar comment before about removing CKM_ECDSA_KEY_PAIR_GEN,
CKA_ECDSA_PARAMS and CKK_ECDSA as they are deperated and replaced by their _EC_ equivalents. But Tim brought up a good point (I think it was Tim, sorry if i’m putting words in your mouth). If we are going to remove the deprecated values, we should
probably do a full sweep and drop all of the depcreated values from the spec and headers. Given the focus on getting 3.0 out, I didn’t follow up on the topic. Once 3.0 was out, I was considering working on a proposal to cleanup/remove all the deprecated
things. I don’t have a strong opinion on this topic other than that we should probably do 1 of 3. 1) do nothing at this time and leave the deprecated values in for now. 2) If we remove CKM_ECDSA_KEY_PAIR_GEN,
then we should remove the deprecated values for all the EC relateded content. 3) Do the full sweep suggested previously. 3489: This list is missing CKM_XEDDSA. Thanks, Daniel
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]