RE: [pkcs11-comment] Query about the PKCS#11 encoding of ECDSA signatures.

[Amine Najahi <anajahi@nvidia.com>]

Hi David,

We were prompted to default to ASN.1 DER because

- We have hardware that produces and consumes encoded signatures in this format.
- We did not see use cases so far where our customers are using ECDSA with other encodings.

Hence, we found it unjustified to strip the encoding just for the caller to put it back in.

I understand your point though that this cannot be changed now due to the multitude of
implementations and there being no easy way to detect a signature's encoding.

Thank you for the clarification,
Amine

-----Original Message-----
From: David Woodhouse <dwmw2@infradead.org> 
Sent: Thursday, August 3, 2023 2:47 PM
To: Amine Najahi <anajahi@nvidia.com>; pkcs11-comment@lists.oasis-open.org
Cc: Andy Guiver <aguiver@nvidia.com>
Subject: Re: [pkcs11-comment] Query about the PKCS#11 encoding of ECDSA signatures.

On Thu, 2023-08-03 at 13:29 +0000, Amine Najahi wrote:
> Dear OASIS PKCS#11 committee members,
> Â
> We wanted to get your position about the âEC Signaturesâ section from
> the standard:
> https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/pkcs11-curr-v3.0-os.html#_Toc30061178
> Â
> The paragraph and the âNoteâ within describe an encoding of ECDSA
> signatures. To our
> knowledge, this encoding (2 octet strings of equal length and padded
> if need be) is not commonly used,
> or at least not as common as the ASN.1/DER encoding.
> Â
> We are considering departing from the standard on this ECDSA
> signature format, and we noticed other
> HSM documentations online are doing the same.

How would this work?

An application or crypto library using PKCS#11 knows that the signature
is a simple binary concetenation of the r and s values, and that it
must create the DER wrapper of two octet-strings from those. Much the
same as with EC signatures from a TPM. For example:

https://github.com/dwmw2/rolesanywhere-credential-helper/blob/pkcs11/aws_signing_helper/pkcs11_signer.go#L601
https://github.com/OpenSC/libp11/blob/master/src/p11_ec.c#L493

When a standard-compliant implementation encounters a token which
"departs from the standard"... how would it know that the token is
broken in such a way, and that what is returned violates the Pkcs#11
specification? Would the application need to have a denylist of broken
token implementations, or would this "feature" be advertised somehow?

> Does the committee have any intention to update/reconsider this
> section in the near future?
> Eventually to allow for alternative encodings?

That doesn't seem like a good idea. The standard seems clear,
implementations already do the right thing, and any changes here are
just going to cause confusion and interoperability failures.

Or am I misunderstanding the proposal?