OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [pkcs11] Groups - EdDSA Using CFRG concept of Octet Key Pairs uploaded


Hey Dieter,

Thanks for the feedback.  I’m almost done updating the CFRG proposal.  I haven’t updated that  last section yet.  But I do agree, we should stick with byte-array/hexadecimal notation.  I agree that adopting JSON strings and base64 encoding is taking things a bit too far.

 

Darren

 

 

From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Dieter Bong
Sent: Friday, November 10, 2017 8:37 AM
To: Johnson Darren <darren.johnson@gemalto.com>; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] Groups - EdDSA Using CFRG concept of Octet Key Pairs uploaded

 

Hi Darren,

 

In the last section of your document, you raise the question of how to encode OKP keys. Until now, keys either plaintext or encrypted/wrapped) are always encoded as byte arrays in hexadecimal notation; and any other representation is left to the application layer. We prefer to keep this rule for OKP keys as well, and leave it to the application to use base64 or any other encoding at application/protocol layer.

 

Thanks,

Dieter

 

From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Darren Johnson
Sent: Donnerstag, 21. September 2017 22:04
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Groups - EdDSA Using CFRG concept of Octet Key Pairs 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 CFRG concept of Octet Key Pairs


Description
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”
Download Latest Revision
Public Download Link


Submitter: Mr. Darren Johnson
Group: OASIS PKCS 11 TC
Folder: Documents
Date submitted: 2017-09-21 13:03:32

 

 



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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]