OASIS PKCS 11 TC

Hi, Here are my latest round of review comments.  Most of them are focused on areas impacted by my proposals, but I did review some other areas of the specs as well.  My comments for the base spec comments are embedded in the attached word document as word comments (sorry for attaching the binary).  My comments for the current mechanism are listed below on a line-by-line basis.   Comments for pkcs11-curr-v3.0-wd06.docx:   EC_KeyGen_w_Extra_Bits proposal does not appear to be in wd06.   Normative and Non-Normative References                 I’m not sure which section these should go in, but the follow references need to be added. - RFC 8032, RFC 7748 from the “Additional ECC Curves” proposal - [BRAINPOOL] and [LEGIFRANCE} from the “Additional ECC Curves” proposal - SP800-108     [RFC 8032]               Aboba et al, “Edwards-Curve Digital Signature Algorithm (EdDSA)”, IETF RFC 8032, January 2017. URL: https://tools.ietf.org/html/rfc8032 .   [RFC 7748]               Aboba et al, “Elliptic Curves for Security”, IETF RFC 7748, January 2016. URL: https://tools.ietf.org/html/rfc7748 .   [FIPS SP 800-108]    NIST. Special Publication 800-108 (Revised) : Recommendation for Key Derivation Using Pseudorandom Functions, October 2009 . URL: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf .   Lines 3426-3427                 This opening paragraph for section 2.3 Elliptic Curve was replace by two new paragraphs in “Additional ECC Curves” proposal. Line 3429                 Table 28 is missing CKM_EDDSA from “Additional ECC Curves” proposal.   Line 3431                 Table 29, should it have a header for each column?                 The description for CKF_EC_OID should use “OID” instead of “oId”, to be consistent with other OID references.   Line 3443, 3446                 The text should use “OID” instead of “oId”, to be consistent with other OID references. Lines 3470-3485                 This section was updated with an additional paragraph to explain EdDSA signature lengths. Lines 3534-3537                 This paragraph needs tweaks.  It should be the following.   This allows detailed specification of all required values using choice ecParameters , the use of a OID as an object identifier substitute for a particular set of elliptic curve domain parameters, or implicitlyCA to indicate that the domain parameters are explicitly defined elsewhere, or curveName to specify a curve name as e.g. define in [ANSI X9.62], [BRAINPOOL], [SEC 2], [LEGIFRANCE].  The use of a OID or a curveName is recommended over the choice ecParameters .  The choice implicitlyCA must not be used in Cryptoki.   Lines 3568-3571                 This paragraph is the same as Lines 3534-3537.  It should be replaced with the same update.   Line 3612                 This should be RFC 8032, not 7748. Line 3644                 This should be RFC 8032, not 7748. Line 3843                 This should be RFC 8032, not 7748.   Lines 3847 and 3850 There are two sections (2.3.15 and 2.3.16) for XEdDSA.  Is that intentional? Section 2.3.17 is also XEDDSA specific.  I would expect 2.3.17 to be merged in to what is currently called 2.3.18 which contains all the other EC related mechanism parameters. I think what is currently 2.3.15 is already in table 28 at the beginning of section 2.3. I think 2.3.16 should be left as-is as its own sub section in 2.3.   Line 3852                 This line has a reference to [ XEDDSA ], is that reference added to the Normative/Non-Normative sections?  I didn’t see it, but may have missed it. Lines 3898-3901                 The alignment for this table is off.   Lines 3959-3990                 This section about ECDH2 is to be removed.  There are currently no mechanisms that reference it.   Line 7892                 The table numbers in this entire section (2.34 SP 800-108 Key Derivation) look wrong.  Some are repeated (ie 34) and the table number resets to “4” at some point. Line 3644                 Same comment, RFC 8032 Lines 7961-7963                 Are these supposed to be “Arial 10”? Line 7988                 ulWidthInBits is not aligned with the other parameters. Lines 7994-7997                 Are these supposed to be “Arial 10”? Line 8012                 ulWidthInBits is not aligned with the other parameters. Lines 8018-8022                 Are these supposed to be “Arial 10”? Lines 8046-8048                 A different font/size is used here compared to surrounding text Lines 8044-8051                 The structure variables are not aligned. Lines 8073-8082                 A mix of font/size is used and the variables are not aligned. Lines 8124                 In table 5, the first column on the second row uses “CK_SP800_108_COUNTER”, but it should read “CKM_SP800_108_OPTIONAL_COUNTER”, as it is an optional parameter. Lines 8136                 In table 6, the first column on the second row uses “CK_SP800_108_COUNTER”, but it should read “CKM_SP800_108_OPTIONAL_COUNTER”, as it is an optional parameter. Lines 8164-8167                 This paragraph can be removed as it is basically repeated two paragraphs above.               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. Attachment: pkcs11-base-v3.0-wd05 - dj_comments.docx Description: pkcs11-base-v3.0-wd05 - dj_comments.docx

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.   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.     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.   3489: This list is missing CKM_XEDDSA.     Thanks, Daniel   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/

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 Sent: Thursday, August 23, 2018 10:56 AM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] RE: PKCS#11 review comments for base spec 3.0 WD05 and curr 3.0 WD06   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     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/ 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.

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] Sent: Donnerstag, 23. August 2018 19:57 To: Daniel Minder <Daniel.Minder@utimaco.com>; pkcs11@lists.oasis-open.org 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 Sent: Thursday, August 23, 2018 10:56 AM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] RE: PKCS#11 review comments for base spec 3.0 WD05 and curr 3.0 WD06   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     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/ 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. 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/