RE: [pkcs11] Groups - EdDSA Using Additional Key Types uploaded

Hi,

Do we think we need additional OIDs?  Given that the OIDs do not exist today, most/all software that use these new curves are using named curves.  We would also
 need to propose the encoding format (the ASN.1 sequence) used to encode the full curve parameters.

 

Unless I misunderstood what you are asking about here?

 

Darren

 

From:  [mailto:]
On Behalf Of Fenwick, Valerie

Sent: Friday, November 10, 2017 1:03 PM

To: Dieter Bong <>; ; Tony Cox <>

Subject: RE: [pkcs11] Groups - EdDSA Using Additional Key Types uploaded

 

I don’t know how OIDs are requested anymore – do you? I’m sure anyone can do it, not sure it has to be an official committee request.

 

Do you know how it’s done?

 

Valerie

 

From: Dieter Bong [mailto:]

Sent: Friday, November 10, 2017 6:22 AM

To: ; Fenwick, Valerie <>; Tony Cox <>

Subject: RE: [pkcs11] Groups - EdDSA Using Additional Key Types uploaded

 

Hi Valerie, Tony,

 

Darren’s proposal #3 mentions the limitation that mechanisms can
 only be called with “named curve” because
 there are currently no OID definitions for Edwards Curves. In case we decide to go ahead with this proposal #3, can the PKCS#11 TC ask for allocation of OIDs for Edwards curve in the OASIS OID tree?

 

Thanks,

Dieter

 

From:
 [mailto:]
On Behalf Of Darren Johnson

Sent: Donnerstag, 21. September 2017 22:02

To: 

Subject: [pkcs11] Groups - EdDSA Using Additional Key Types uploaded

 

Submitter's message

This submission is one of three proposal submissions. I am uploading three different proposals on how we can include RFC 8032 (Ed25519 and Ed448) and RFC 7748 (Curve25519 and Curve 448) in PKCS #11.

Note that all three proposals are incomplete at many levels, so keep that in minde. The purpose of uploading them is to get feed back on which approach makes the most sense.

Three proposals:

1) A proposal to add an RFC 8032 and RFC 7748 specific section to the existing “2.3 Elliptic Curve”. This proposal re-uses the existing EC key types and provides guidance on how these curves and algorithms can be used.

2) A proposal to adopt the CFRG concept of Octet Key Pairs (RFC 8037). OKP’s are defined as new key types completely separate from the existing “2.3 Elliptic Curve”.

3) A proposal that introduces two new EC key types that are based on the three EC curve representations in use today. The existing “2.3 Elliptic Curve” section is based on X9 which takes for granted that everything is using Weierstrass representation. This
 proposal defines an EC key type for Edwards Curves (RFC 8032) and an EC key type for Montgomery Curves (RFC 7748)

-- Mr. Darren Johnson 

Document Name:

EdDSA Using Additional Key Types

Description

3) A proposal that introduces two new EC key types that are based on the

three EC curve representations in use today. The existing “2.3 Elliptic

Curve” section is based on X9 which takes for granted that everything is

using Weierstrass representation. This proposal defines an EC key type for

Edwards Curves (RFC 8032) and an EC key type for Montgomery Curves (RFC

7748) 

Download Latest Revision

Public Download Link

Submitter: Mr. Darren Johnson

Group: OASIS PKCS 11 TC

Folder: Documents

Date submitted: 2017-09-21 13:01:53

 

 

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/

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.