[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [pkcs11] Message* functions
All, Bob wrote: Except C_EncryptMessage would look like it was supposed to include MessageFinal (in all or other examples). This was the primary reason for making
the inner functions with swapped names (particularly since the inner functions can themselves be multi-part). That’s why I also suggested to rename C_EncryptMessageFinal to C_EncryptMessageEnd to emphasize the different usage. If “Final” is what people distracts the solution should be to rename “Final” and not to
change the common prefix of functions that belong together. I believe sloven belief in 'consistent' naming without nuance can be dangerous. AEAD in many ways is a new animal. The spec as given had a *LOT*
of thought go into how the spellings should be for the functions. When the spec was presented in it's numerous cases, the spellings were pointed out for comment.
Was it this discussion?
https://wiki.oasis-open.org/pkcs11/MeetingMinutes/Minutes015042015 says “In all instances the semantics are to change to ‘C_MessageEncrypt..’ – Init and Final should be changed to be consistent. (C_MessageEncrypt -> C_EncryptMessage & C_MessageDecrypt ->
C_DecryptMessage)” The reason is not given here, and actually I don’t fully understand the comment, especially the “C_MessageEncrypt -> C_EncryptMessage” part since there is no C_MessageEncrypt in the proposal except for C_MessageEncryptInit and C_MessageEncryptFinal.
So, maybe it was meant to change it to what I proposed? Changing it at the last minute because it doesn't meet a particular aesthetic puts aside the thought that was originally put into the text. I acknowledge the thoughts but see my comment above for a better solution that solves the original problem as well. Second, I’ve received some private mails supporting my view. And third, it’s not a question
of aesthetics but a question of good software engineering. Or as someone in a private mail wrote:
To me, this looks like one of those things that people who aren’t familiar with it, later, are going to look at it and ask “Why?”. My point about the length of time. It's been 2 years (it took a year before the approval vote). That was plenty of time to review and bring up
issues of function spellings. I believe we just need to say 'it's settled' and move on. I agree that the proposal took quite long. It appeared first in March 2014 from Wan-Teh (https://www.oasis-open.org/committees/document.php?document_id=52895&wg_abbrev=pkcs11),
disappeared from the agenda, reappeared in Feb 2016 (https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes25022016), was not discussed afterwards for months, reappeared again
beginning of 2017 and was finally agreed upon. However, the problem was not that there was too much discussion but slow feedback. And even in the final proposal that was reviewed and went to the working draft there are a few errors (see my posted WD03 rework).
Therefore, I’m really wondering how good the reviews have actually been… What we put into PCKS#11 3.0 now will live for quite some time and will be very hard to change – if at all. Therefore, we should really put a lot of effort into reviewing it and pointing to problems. Everything
what’s in the Working Draft right now was already agreed. Nevertheless, we will still find problems beside editorial mistakes. But why shouldn’t we fix them if there are good solutions before the release? Best, 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/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]