[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Comments from Darren J (repost)
Bob, all,
See my mail od Apr 10. This has all been already resolved.
There is another mail/document of Darren that needs attention. All information is in my mail...
Thanks
Daniel
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------
Von: Robert Relyea <rrelyea@REDHAT.COM>
Datum: 18.04.19 18:25 (GMT+01:00)
An: pkcs11@lists.oasis-open.org
Betreff: Re: [pkcs11] Comments from Darren J (repost)
On 04/09/2019 10:40 PM, Tony Cox wrote:
CKF_EC_CURVENAME replaces CKF_EC_OID which was deprecated. The former is in the identifiers database and the latter is in the aliases database (identifiers that we've renamed, but kept the old definition I have a proposal in the So IIRC the only oids that matter in PKCS #11 is the key+params oids. Applications have to map signature oids from their ANS.1 encoded signatures and map them to the appropriate mechanisms. The only exception is if the oid is imbedded in the signature (as it is in RSA). I don't think that's the case with EDDSA. I think the 4 oids that we are talking about here are the key_params oids, so Darren's question is still relevant. It seems 2a would be consistent with restricting keys to particular functions (the generated key was specifically EDDSA). 2b would be more flexible (from the application perspective). Restricted functionality could still be controlled with the existing CKA_SIGN/CKA_DERIVE flags on the key itself. So I'm OK with either one here.
We should probably include the table, or text that mirrors the table. The use of CKK_EC_MONTGOMERY with EC_DH seems like the right semantic to me (we are already doing that in our code). I think in cases where multi-part does not make sense or can't be implemented, we should probably call that out in the spec. The module implementer would know it had to be single-part, but the application may not. It's pretty common for the raw asymmetric sign/verify code to be single-part only, so EdDSA wouldn't be unique. bob
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: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Dr. Frank J. Nellissen CFO This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]