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: [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]