RE: [pkcs11] intro and proposals

["Fenwick, Valerie" <valerie.fenwick@intel.com>]

Hi Daniel  -

We haven't had a written rule on this, but we have generally at least wanted the standardization to be in progress. Due to the length of standardization processes in general (across all standards body), we sometimes start shaping proposals here, following along with that work - so we can hopefully be ready at about the same time.

We had discussed in the 2.40 time frame that we would release "committee specification drafts" to cover new mechanisms that didn't quite make the spec, but we had not done that work (though it is still an option). Instead, we focused on 3.00

So - if the process of standardizing the algorithm is far along and looks likely to succeed, we can go forward. If not... they may be better to wait on. It's a committee call, but I believe it's important to clarify where something is in other standard's bodies.

Valerie


-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Daniel Minder
Sent: Tuesday, January 16, 2018 10:17 AM
To: Stefan Marsiske <oasis@ctrlc.hu>; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] intro and proposals

All,

concerning Stefan Marsiske's four proposals I'm wondering if there are requirements for an algorithm/mechanism to be included in the PKCS#11 standard. In my opinion an algorithm should be standardized to be considered for inclusion. We might consider exceptions for old algorithms that have been adopted by a larger community. If this is the "golden rule" half of Stefan's proposals should NOT be included at the moment.


Chacha:

Chacha20 in the IETF variant has been standardized in RFC7539. For the original version, there is DJB's paper. However, for Xchacha20 there is nothing but some implementations and, therefore, I doubt we should include it.

I see two different approaches for the IETF and DJB variant since struct CK_CHACHA20_PARAMS is not different from struct CK_CHACHA20_IETF_PARAMS:

1. CK_CHACHA20_PARAMS already includes field ulIvLen. Thus, the two variants could simply be distinguished by using this field, and the mechanism can always be called CKM_CHACHA20.

2. Mechanisms are distinguished by their name. However, I would name the IETF version CKM_CHACHA20 since I assume that this will be more widely adopted (e.g. in TLS, RFC7905). DJB's version could be named CKM_CHACHA20_ORIGINAL (or _DJB). Field ulIvLen can be removed from CK_CHACHA20_PARAMS but we should clarify in the description of the other fields that different lengths must be used depending on the selected algorithm.

For both approaches, CK_CHACHA20_IETF_PARAMS would not be needed at all.

If prefer the first approach.



Salsa:

Same comment as for Chacha applies to the CK_SALSA20_PARAMS and CK_XSALSA20_PARAMS structs.

Section 1.2.6 not needed here in Salsa section.

Reference [SALSA] is missing in the proposal.



Blake2:

Since table for Key Derivation Functions is only extended explanations for CKD_SHA1_KDF should not be removed from the text. The list of Blake2 KDFs could be formulated as in current working draft to be consistent: "The key derivation functions CKD_BLAKE2B_[160|256|384|512]_KDF, which are based on..."

It is probably not intentional to delete SHAKE.

If new mechanisms for DSA and RSA shall also be defined (see proposed header file changes) explanatory text is missing in appropriate sections.

There are inconsistencies between text (CKM_BLAKE2B_256_KEY_DERIVATION) and header file definitions (CKM_BLAKE2B_256_KEY_DERIVE) - the text is right.



XEdDSA / x3dh / Double Ratchet:

All definitions are located on https://signal.org/docs/ only, and there is no official standard available. I agree that the Signal protocol has been adopted by others in the meantime. Nevertheless, I would like to see a standard first - see my initial comment.

Apart from that:

For XEdDSA I agree to Darren's comments.

For x3dh table 4, the same comment as for XEdDSA key derivation functions applies.

In DoubleRatchet table 6, all attributes should include a term "DOUBLERATCHET" or similar since "CKA_RK" would be too general otherwise.

Field eCurve in CK_X2RATCHET_INITIALIZE_PARAMS and CK_X2RATCHET_RESPOND_PARAMS could be consistent with the EdDSA proposal, i.e. specifying it as string "curve25519" and "curve448".

DoubleRatchet section 2.5 seems to be copied mostly from x3dh without renaming to CK_X2RATCHET_KDF_TYPE. Above comments on the KDF types apply here as well.



Kind regards,
Daniel

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Stefan Marsiske
Sent: Dienstag, 19. Dezember 2017 15:06
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] intro and proposals

Dear PKCS#11 TC,

I'm Stefan Marsiske (quite googleable for personal details, which I omit for that reason) - new to the TC, I joined a bit before the summer, but was lurking so far. I became a member to add a few mechanisms. I have been triggered by Tim&Tony 2 weeks ago, that the window for 3.0 is closing and if I want to I should overcome my shyness.

The mechanisms I would like to propose for inclusion in PKCS#11 (preferably v3.0) are: Salsa20, XSalsa20, Chacha20[*], XChacha20, Blake2b, XEDDSA, Extended Triple DH, Double Ratchet.

[*] the accepted Chacha20 is in fact the IETF variant, which uses a different nonce and is only capable of handling 256GB maximum with the same key/nonce pair.

I will send four separate mails with each proposal and some more details, so we can compartmentalize the discussions for each proposal.

ho ho ho,
merry xmas,
stefan

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



________________________________

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/