[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
|
All, As written in my comments: removal of line 3429 was only added since it was already removed in line 3491 (not by myself). I.e. either we remove both or none. In the header file I count 14 deprecations, 2 in the base spec, and 5 in the mech spec (not included the new one for namedcurve). However, not all macros deprecated in the header file are marked as deprecated in the word documents. In a
final round we should add these deprecation marks to notify people and then remove all deprecations in the next revision of the standard. Have a nice week-end Daniel From: Johnson Darren [mailto:darren.johnson@gemalto.com]
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. Utimaco IS GmbH Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com Seat: Aachen – Registergericht Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]