Re: [pkcs11] Review before next meeting

[Robert Relyea <rrelyea@redhat.com>]

On 06/06/2016 07:35 AM, Dieter Bong wrote:
> All,
>
> here are my comments.
>
> Updated AEAD Proposal (not repeating what other people already commented)
> * Page 2, bottom, "For most mechanisms, C_EncryptMessage is equivalent to C_EncryptMessageBegin followed by a sequence of C_EncryptMessageNext operations. " : It would be useful to mention in which cases C_EncryptMessage is NOT equivalent to C_EncryptMessageBegin followed by a sequence of C_EncryptMessageNext operations, if any. Idem for decryption (page 7), signing (page 13) .
There currently isn't any case. The text says 'for most mechanism'. 
There are currently only two mechanisms defined for these functions 
AES-GCM and AES-CCM. The words are there to allow flexibility in case it 
may make sense for future mechanisms.

These should be fixed in the current document
> * Page 6, line 8: continues o rfinishes -> continues or finishes
> * Page 6, line 14: dot at the end of the line.
> * Page 11, line 7: signs as ingle-part -> signs a single-part
> * Page 11, line 18: MessagedSignInit -> MessageSignInit
> * Page 13, lines 14 and 19: insert space in pParameterand, ulParameterLenspecify and pParametermay
> * Page 17, line 13: for for -> for
> * Page 19, line 18: .. -> .
> * Page 20, lines 4-8: insert space between parameter type and name
> * Page 20, line 15: pSignatureargument -> pSignature argument
> * Page 21, table 8: CKF_MULTI_MESSGE -> CKF_MULTI_MESSAGE.
> * Page 22: C_SignRecover is possibly a left-over from the original table 30?

> * Throughout the whole document : Consistently use Courier font for parameter names inside the text.
I've left this for the editor as he may have preferred ways of marking 
these elements in the document.
> AES GCM Changes:
> * I have added my feedback using track changes (only up to and including page 11)
I'm not sure where those are?
> * Page 3 and 5: The meaning of the following section is not clear to me: " The key type for K must be compatible with CKM_AES_ECB and the C_EncryptInit/C_DecryptInit calls shall behave, with respect to K, as if they were called directly with CKM_AES_ECB, K and NULL parameters. "
This text was from the existing document. I've updated it to say 
key_type is CKK_AES, but I've kept the 'behavioral' comment with the not 
that this only applies to Encrypt/Decrypt, not the Message functions.
> Thanks,
> Dieter
>
> On May 31, 2016, at 2:45 PM, Valerie Fenwick <valerie.fenwick@oracle.com> wrote:

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature