Subject: [lamps] LAMPS Minutes for IETF 109

From: Russ Housley <[email-masked]>
Date: Wed, 25 Nov 2020 17:43:18 -0500

https://datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00

Please send a note is you see anything that needs to be corrected.

Thanks Jonathan.  Your notes were excellent.

Russ

---

From: Rene Struik <[email-masked]>
Date: Thu, 26 Nov 2020 15:57:41 -0500

Dear colleagues:

Do you think supporting ECDSA25519 would make sense as well?

This is well-defined and non-deterministic and also can use existing Curve25519 ladders under the hood (see [1]) as well as existing generic hardware supporting short-Weierstrass curves (see [2]).

Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve draft [3], it seems this could just be used without further ado.

Best regards, Rene

Ref:
[1] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-14#section-4.3
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations#section-6
[3] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations

==

[excerpt of draft minutes]

Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and RSASSA-PSS. Russ mentioned that signing with Ed25519 (uses Curve25519) is gaining support.  Russ (and several in chat) suggested dropping DSA. No objections.

On 2020-11-25 5:43 p.m., Russ Housley wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 27 Nov 2020 07:30:47 +0100

My two cents.

Working with hardware security modules it's a bit of a pain as it is
with EdDSA. As PKCS#11 supports it in PKCS#11v3 which is not yet widely
available in implementations you have to do custom coding for each
hardware module. Adding more options for users, that are not broadly
available makes it confusing and hard to make (cost effective) choices.

Therefore I would not like to add algorithms that have not yet gained
wide support.

We also see that Ed25519 is gaining support (P11v3 is making inroads),
making that logical to add.

I also have not used DSA, or heard any requests for it, for about 10
years or so. I support dropping it.

Best regards,
Tomas

---

From: Rene Struik <[email-masked]>
Date: Fri, 27 Nov 2020 09:41:22 -0500

Hi Tomas:

Thanks for your note. It would help to understand somewhat more your 
"custom encoding" remark. (I do think this would be enlightening in 
general, since HW insights are not widely available within IETF).

Also, I would be curious which version of Ed25519 is gaining support 
(there are many), since the deterministic scheme specified in RFC 8032 
has come under criticism [1]. In fact, this motivated my suggestion to 
use ECDSA25519 and to provide something that at least has been known to 
work effectively (and without buffering issues).

Could you provide a pointer to the PKCS11v3 specification that provides 
all technical details? (or, is this behind a paywall)?

Ref: [1] 
https://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-02

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 30 Nov 2020 08:26:36 +0100

Hi,

I'm glad to give more information. Luckily PKCS#11 is also an open
standard, under Oasis.
https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/pkcs11-base-v3.0-os.html

Background
---
PKCS#11 is probably the most common API to interface, in a standards
interoperable way, with crypto hardware such as HSMs, smart cards, USB
tokens and the like. It is a C API, ageing in technology, but it has
served us well for the last 25 years. I'll dare to say that despite it's
shortcomings it has served us very well, and i one of the few
technologies that have delivered on the promise "write once, run
everywhere".
Writing C, Java, Python, C# code using PKCS#11 against one crypto
module, it is likely to work with another from another vendor only with
proper configuration of the vendor driver (usually a config file to tell
the PKCS#11 driver, .so lib file, where the module is, and some vendor
specific configuration).

It is what many (most) clients use to communicate with hardware tokens.
FOr example if you want to use a smart card for TLS client
authentication, FireFox, Chrome and Safari uses PKCS#11 to talk to your
smart card. If you want to sign an email with S/MIME your email client
(for example Thunderbird) uses PKCS#11 to talk to the smart card or
USB-token. If you issue certificates or create remote server side
signatures (eIDAS) the server (CA or signing server) user PKCS#11 to
talk to the HSM.

Ed25519 specifics
-----
PKCS#11 uses mechanisms (long values. In P11v3 you can generate an
Ed25519 key pair.
https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/pkcs11-curr-v3.0-os.html#_Toc30061187

Ed25519 is defined here in the standard as RFC 8032 and RFC 8410.

Typically, in P11v3, you provide the OID of Ed25519, RFC 8410. Many
vendors implemented this before the final version of P11v3 was out, and
then used names such as curve25519 or Ed25519 to the key pair generation
function. Resulting in if's in the code doing key generation (no write
once run everywhere any more).

The same with signatures:
https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/pkcs11-curr-v3.0-os.html#_Toc30061191
The CKM_EDDSA is a constant (0x00001057L in P11v3). But vendors
implementing it before, and that haven't moved to P11v3 yet use their
own "vendor defined" mechanisms, for example (0x80000000L + 0xC03L).
Some more if's in the code when signing data.

Conclusion:
-----

So maybe I take my hesitation back a little bit.
- Starting to use a new algorithm with hardware devices is a PITA if
standardization hasn't gone the complete mile.
Usually I see it go a bit like this:
- IETF standardizes the algorithm itself, for usage in RFCs
- IETF standardizes OIDs
- IETF standardizes usage in other RFCs (Certificates, S/MIME, TLS, etc)
- Oasis takes on and standardizes usage in PKCS#11

With take it back I mean that a prerequisite for it getting into PKCS#11
is that the needed RFCs exist. So if it should be used, it must be
standardized in RFCs first. Then it may take years before it's actually
used, but that's another story. New algorithms take a long time to get
into P11, but variations (new hash algorithms, new EC curves but the
same signature math) are quicker and are put into point updates of P11.

The same goes for PQC algorithms btw.

Cheers,
Tomas

On 2020-11-27 15:41, Rene Struik wrote:
>>> This is well-defined and non-deterministic and also can use existing
>>> Curve25519 ladders under the hood (see [1]) as well as existing
>>> generic hardware supporting short-Weierstrass curves (see [2]).
>>>
>>> Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve
>>> draft [3], it seems this could just be used without further ado.
>>>
>>> Best regards, Rene
>>>
>>> Ref:
>>> [1]
>>> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-14#section-4.3
>>>
>>> [2]
>>> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations#section-6
>>>
>>> [3]
>>> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations
>>>
>>>
>>> ==
>>>
>>> Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and
>>> RSASSA-PSS. Russ mentioned that signing with Ed25519 (uses
>>> Curve25519) is gaining support.  Russ (and several in chat) suggested
>>> dropping DSA. No objections.
>>>
>>>
>>>
>>>