RE: [pkcs11] Groups - AEAD proposal draft 3 uploaded

[Dieter Bong <Dieter.Bong@utimaco.com>]

I think there is a number of use cases where multi-part operations will never be used, i.e. encryption or signing will always deal with "short" data packages, e.g. certificate/OCSP signing, time stamping, (payment) transaction processing, etc. All these applications would profit from an atomic function combining today's init and encrypt/sign calls, both in terms of performance and ease of implementation.

I therefore support the idea of a single part API with integrated init.

Best regards,
Dieter

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Johnson Darren
Sent: Montag, 14. November 2016 15:43
To: valerie.fenwick@oracle.com; rrelyea@redhat.com; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] Groups - AEAD proposal draft 3 uploaded

I think this is a good idea.

I think we should also consider supporting a similar single part API for some of the existing APIs (ie C_Encrypt, C_Sign...).

DJ

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Valerie Fenwick
Sent: Monday, November 14, 2016 6:14 AM
To: Robert Relyea <rrelyea@redhat.com>; pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Groups - AEAD proposal draft 3 uploaded

As you might be able to tell, doing in person meetings with some of my crypto heads this week :-)

Question came up:

Why can't we have a truly "single operation" call?

That is, combine:
•       C_MessageEncryptInit
and
•       C_EncryptMessage

So it's only necessary to call "C_EncryptMessage" as a truly single call?

That way, the library implementing the functions will also know from the first call that this is a single part operation and can act accordingly?

This may have come up, and I may have just forgotten... thanks!

Valerie

On 7/21/2016 10:30 PM, Robert Relyea wrote:
> /Submitter's message/
> Fix numerous typos.
> Make the Requirement to call C_MessageXXXXInit() explicit in the
> descriptions of
> C_XXXXMessage() and CXXXXMessgeBegin
> Fix conflicting flag values.
>
> This should address most of the comments I received on AEAD
> -- Mr. Robert Relyea
> *Document Name*: AEAD proposal draft 3
> <https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?doc
> ument_id=58565>
> ----------------------------------------------------------------------
> ----------
> *Description*
> Fix numerous typos.
> Make the Requirement to call C_MessageXXXXInit() explicit in the
> descriptions of C_XXXXMessage() and CXXXXMessgeBegin Fix conflicting
> flag values.
>
> This should address most of the comments I received on AEAD Download
> Latest Revision
> <https://www.oasis-open.org/apps/org/workgroup/pkcs11/download.php/585
> 65/latest/AEAD_proposal.doc>
> Public Download Link
> <https://www.oasis-open.org/committees/document.php?document_id=58565&;
> wg_abbrev=pkcs11>
> ----------------------------------------------------------------------
> ----------
> *Submitter*: Mr. Robert Relyea
> *Group*: OASIS PKCS 11 TC
> *Folder*: Working Drafts
> *Date submitted*: 2016-07-21 15:30:21
>

--
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

________________________________

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/