OASIS PKCS 11 TC

All,   We should re-think the naming of the AEAD message* functions. For example, for encryption we have: C_MessageEncryptInit C_EncryptMessage C_EncryptMessageBegin C_EncryptMessageNext C_MessageEncryptFinal   Why do 2 functions have C_MessageEncrypt prefix and 3 functions C_EncryptMessage prefix? This is quite insconsistent!   We should fix it now.   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/

On 01/12/2018 06:35 AM, Daniel Minder wrote: All,   We should re-think the naming of the AEAD message* functions. For example, for encryption we have: C_MessageEncryptInit C_EncryptMessage C_EncryptMessageBegin C_EncryptMessageNext C_MessageEncryptFinal   Why do 2 functions have C_MessageEncrypt prefix and 3 functions C_EncryptMessage prefix? This is quite insconsistent! We talk about that naming over 2 years ago. It was that way on purpose. The swap is to help emphasis the nested nature. This spec went through many iterations in the early days, it's been out for review for a couple of years now. I don't think now is the time to switch back. bob   We should fix it now.   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/

Bob, all,   Well, the naming was indeed proposed almost two years ago, but I couldn’t find any evidence in the list archive or in the meeting minutes that it was really discussed.   Having C_EncryptMessageInit and C_EncryptMessageFinal as “bracket” is as obvious as C_MessageEncryptInit and C_MessageEncryptFinal, but it has the advantage that everything dealing with message encryption starts with C_EncryptMessage.   For normal encryption, you start with C_EncryptInit and then use C_Encrypt or C_EncryptUpdate+C_EncryptFinal.   For the message encryption, you should also start with C_EncryptMessageInit and then use C_EncryptMessage or C_EncryptMessageBegin+C_EncryptMessageNext. In all cases you finish with C_EncryptMessageFinal – or even better rename it to C_EncryptMessageEnd to stress the different intention of this function.   In my opinion, consistent naming is important the help users of the standard. Yes, the spec was reviewed and voted ok one year ago. But the standard is not released yet.   Thanks, Daniel   From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Robert Relyea Sent: Freitag, 12. Januar 2018 19:46 To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Message* functions   On 01/12/2018 06:35 AM, Daniel Minder wrote: All,   We should re-think the naming of the AEAD message* functions. For example, for encryption we have: C_MessageEncryptInit C_EncryptMessage C_EncryptMessageBegin C_EncryptMessageNext C_MessageEncryptFinal   Why do 2 functions have C_MessageEncrypt prefix and 3 functions C_EncryptMessage prefix? This is quite insconsistent! We talk about that naming over 2 years ago. It was that way on purpose. The swap is to help emphasis the nested nature. This spec went through many iterations in the early days, it's been out for review for a couple of years now. I don't think now is the time to switch back. bob   We should fix it now.   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/   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/

Hi Daniel –   I had brought this up, I thought on the list.  We had also asked for an atomic function (ie no need to call Init if you’re doing only C_Encrypt, for example). Though it was a long time ago. Darren Moffat may have chimed in on that thread (that was when I was at another company and I no longer have access to those old saved emails)   Valerie   From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Daniel Minder Sent: Tuesday, January 16, 2018 10:14 AM To: Robert Relyea <rrelyea@REDHAT.COM>; pkcs11@lists.oasis-open.org Subject: RE: [pkcs11] Message* functions   Bob, all,   Well, the naming was indeed proposed almost two years ago, but I couldn’t find any evidence in the list archive or in the meeting minutes that it was really discussed.   Having C_EncryptMessageInit and C_EncryptMessageFinal as “bracket” is as obvious as C_MessageEncryptInit and C_MessageEncryptFinal, but it has the advantage that everything dealing with message encryption starts with C_EncryptMessage.   For normal encryption, you start with C_EncryptInit and then use C_Encrypt or C_EncryptUpdate+C_EncryptFinal.   For the message encryption, you should also start with C_EncryptMessageInit and then use C_EncryptMessage or C_EncryptMessageBegin+C_EncryptMessageNext. In all cases you finish with C_EncryptMessageFinal – or even better rename it to C_EncryptMessageEnd to stress the different intention of this function.   In my opinion, consistent naming is important the help users of the standard. Yes, the spec was reviewed and voted ok one year ago. But the standard is not released yet.   Thanks, Daniel   From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of Robert Relyea Sent: Freitag, 12. Januar 2018 19:46 To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Message* functions   On 01/12/2018 06:35 AM, Daniel Minder wrote: All,   We should re-think the naming of the AEAD message* functions. For example, for encryption we have: C_MessageEncryptInit C_EncryptMessage C_EncryptMessageBegin C_EncryptMessageNext C_MessageEncryptFinal   Why do 2 functions have C_MessageEncrypt prefix and 3 functions C_EncryptMessage prefix? This is quite insconsistent! We talk about that naming over 2 years ago. It was that way on purpose. The swap is to help emphasis the nested nature. This spec went through many iterations in the early days, it's been out for review for a couple of years now. I don't think now is the time to switch back. bob   We should fix it now.   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/     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/

On 01/16/2018 10:13 AM, Daniel Minder wrote: Bob, all,   Well, the naming was indeed proposed almost two years ago, but I couldn’t find any evidence in the list archive or in the meeting minutes that it was really discussed.   Having C_EncryptMessageInit and C_EncryptMessageFinal as “bracket” is as obvious as C_MessageEncryptInit and C_MessageEncryptFinal, but it has the advantage that everything dealing with message encryption starts with C_EncryptMessage.   For normal encryption, you start with C_EncryptInit and then use C_Encrypt or C_EncryptUpdate+C_EncryptFinal.   For the message encryption, you should also start with C_EncryptMessageInit and then use C_EncryptMessage or C_EncryptMessageBegin+C_EncryptMessageNext. In all cases you finish with C_EncryptMessageFinal – or even better rename it to C_EncryptMessageEnd to stress the different intention of this function. 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).   In my opinion, consistent naming is important the help users of the standard. Yes, the spec was reviewed and voted ok one year ago. But the standard is not released yet. 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. 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. 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. bob   Thanks, Daniel   From: pkcs11@lists.oasis-open.org [ mailto:pkcs11@lists.oasis-open.org ] On Behalf Of Robert Relyea Sent: Freitag, 12. Januar 2018 19:46 To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Message* functions   On 01/12/2018 06:35 AM, Daniel Minder wrote: All,   We should re-think the naming of the AEAD message* functions. For example, for encryption we have: C_MessageEncryptInit C_EncryptMessage C_EncryptMessageBegin C_EncryptMessageNext C_MessageEncryptFinal   Why do 2 functions have C_MessageEncrypt prefix and 3 functions C_EncryptMessage prefix? This is quite insconsistent! We talk about that naming over 2 years ago. It was that way on purpose. The swap is to help emphasis the nested nature. This spec went through many iterations in the early days, it's been out for review for a couple of years now. I don't think now is the time to switch back. bob   We should fix it now.   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/   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/