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] 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/


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