OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [pkcs11] Groups - pkcs11-curr-v3.0-wd08_comments_darren_johnson_20180205.docx uploaded


Hi,

I provided some feedback inline below.

But I suspect we'll discuss most of this on the call.



Thanks

Darren



From: Daniel Minder [mailto:Daniel.Minder@utimaco.com]
Sent: Wednesday, February 06, 2019 10:42 AM
To: Johnson Darren <darren.johnson@gemalto.com>; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] Groups - pkcs11-curr-v3.0-wd08_comments_darren_johnson_20180205.docx uploaded



Hi Darren, all,



I agree to all of your comments. For CK_OTP_PARAMS I don't know.

[DJ] Hopefully we'll get some more opinions on this topic on the call.



Removing deprecated items is a good thing - however when searching for "deprecate" in wd08 I found CKM_ECDSA_KEY_PAIR_GEN (which we can remove), CFK_EC_NAMEDCURVE (which is a new deprecation in 3.0 and must stay) and CKM_TLS_PRF (which seems to be still necessary for backwards compatibility?).



There are more definitions marked as deprecated in pkcs11t.h.

Some of the do not appear in the spec document and could be removed:

CKK_CAST5

CKA_SECONDARY_AUTH

CKA_AUTH_PIN_FLAGS

CKM_CAST5_CBC

CKM_CAST5_MAC

CKM_CAST5_MAC_GENERAL

CKM_CAST5_CBC_PAD

CKM_PBE_MD5_CAST5_CBC

CKM_PBE_SHA1_CAST5_CBC

CK_AES_GCM_PARAMS

CK_AES_CCM_PARAMS

However, some other appear there together with their alternative form, but it is not indicated that they are deprecated:

CKK_ECDSA

CKA_ECDSA_PARAMS

Thus, can we really remove now the latter? If we agree, let's remove all of them.



[DJ]  Some of the items listed above are in the historical mechanisms document (ie CAST5 etc).  I was under the impression (right or wrong) that we keep those in the header files.  I guess we can clarify that tonight on the call.



For other truly deprecated items (marked deprecated either in the spec or the header files) I think they should be removed for 3.0.  I think we can discuss all of this on the call to get wider consensus.



Late 2017, we had an email discussion on this topic (https://markmail.org/message/avfn4mu5brb63u4o?q=deprecated+list:org%2Eoasis-open%2Elists%2Epkcs11) where multiple people seemed to like the idea of this cleanup activity.  But I don't remember where that thread ended up, and I don't see any follow-up discussions in the minutes.  So maybe we never finished the discussion?



Concerning comments in OTP chapter: I think the paragraphs following the figures should start with "Figure x".

[DJ] agreed.



It seems that the whole OTP chapter appears twice: the one following section 2.53.2 should be removed (also has wrong section numbers and does not appear in the TOC).

[DJ] I thought the one following 2.53.2 is already removed?  In my version it is marked as deleted.  The only thing remaining is the actual tables.  If I accept the "moved text", it looks like the tables get cleaned up as well.

So no activity required on this one?



Concerning footnote 15: If the footnote doesn't fit in the remaining space on the same page it is continues on the next one. Otherwise, we would have to insert a manual page break before table 193, but have to take check it every time we change the document. Maybe this problem disappears if we remove/add text before.

[DJ] I thought word would reformat on the fly to make things fit.  There is already a natural space between the two tables where it could naturally make it fit.

If we do want to fix this, I found this tip online to tell word to force the footnote to be grouped together.   It seems to work.



"Highlight the text of the footnote, the go to Paragraph > Line and Page Breaks, then choose "Keep with next" and "Keep lines together".  This will keep your footnote from breaking across pages"



In the text on CK_OTP_SIGNATURE_INFO, there is a reference on "the convention described in Section 11.2 on producing output" - I guess this is again a reference to base spec v2.20, where this was section 11.2.  Now, it's 5.2 and we should mention that it's the base spec.

[DJ] agreed.





Best,

Daniel





From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Darren Johnson
Sent: Mittwoch, 6. Februar 2019 03:43
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Groups - pkcs11-curr-v3.0-wd08_comments_darren_johnson_20180205.docx uploaded



Submitter's message
Here are my latest comments to PKCS#11 3.00 Mechanism specification working draft 08.

Most of the comments should be non controversial.

I made a number of comments to the OTP sections. But I have to admit I am not familiar with the OTP standards. So hopefully they somewhat relevant.
-- Mr. Darren Johnson

Document Name: pkcs11-curr-v3.0-wd08_comments_darren_johnson_20180205.docx

  _____

Description
My comments to PKCS#11 3.00 Mechanism specification working draft 08.
Download Latest Revision
Public Download Link

  _____

Submitter: Mr. Darren Johnson
Group: OASIS PKCS 11 TC
Folder: Documents
Date submitted: 2019-02-05 18:42:31





  _____


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: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]