RE: IETF input on CFRG support in Java. And PKCS #11?

[Dieter Bong <Dieter.Bong@utimaco.com>]

All,

In general I support alignment. And I also support new key types to represent Edwards curves. But if I understand RFC8037 correctly they are using a base64 encoding, which is not used anywhere in PKCS#11 for representation of keys. I would thus not want to go as far as introducing their exact key representation.

Best,
Dieter

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Fenwick, Valerie
Sent: Samstag, 5. August 2017 01:12
To: Johnson Darren <darren.johnson@gemalto.com>; pkcs11@lists.oasis-open.org
Subject: [pkcs11] RE: IETF input on CFRG support in Java. And PKCS #11?

Thanks, Darren. My 2cents is alignment, where possible, seems like a great goal! Crypto is hard enough, right?  I don't work with an implementation team anymore, though, so Bob or others may have stronger opinions.

Valerie

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Johnson Darren
Sent: Friday, August 4, 2017 11:33 AM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] FW: IETF input on CFRG support in Java. And PKCS #11?

Hi all,
as discussed on the call...  Anders Rundgren sent this email to Tim and myself.  He pulled our names from the PKCS page.

It looks like the CFRG/IETF group has defined a new key type to represent the newer Montgomery and Edwards curves; specifically Curve25519, Curve448,  Ed25519 and Ed448 as those are the curvesthey are currently interested in.  As opposed to extending their existing EC structures, they have defined a OKP (octet key pair) for managing key pairs that use octet strings as public and private keys.  RFC8037 covers the new key type while RFC8032 and RFC7748 covers most of the curve primitives... but there is a whole tree of RFCs around this stuff.

Originally I had the impression that CFRG was trying influence other bodies and working groups (ie Java, .NET and PKCS) to adopt the same scheme.  But now that I read more it looks more like that is just a suggestion/hope that some people expressed, that this approach will be adopted by other bodies as they did not want to see things diverge too much.

What are our thoughts on aligning the standards?

I know that Bob's team has already implemented Curve25519 using the existing EC framework, and we (SafeNet) have implemented both Curve25519 and Ed25519 in our products using new key type based on the existing EC framework.  So we know there no hard need/requirement to adopt OKP from CFRG... but is there a good reason no to?

Thanks
Darren

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
Sent: Thursday, July 27, 2017 1:11 AM
To: Tim Hudson <tjh@cryptsoft.com>
Cc: Johnson Darren <darren.johnson@gemalto.com>; Johnson Darren <darren.johnson@gemalto.com>
Subject: IETF input on CFRG support in Java. And PKCS #11?

Hi Tim et al,

This should be of some interest.
https://mailarchive.ietf.org/arch/msg/curdle/GVHazpHuUxq5H7PShB0AFE8DQZI

Jim Schaad is as you probably know an esteemed cryptographer in IETF.

Recently upgraded: https://github.com/cyberphone/java-cfrg-spec

Cheers,
Anders

Pardon the two Darrens, I couldn't figure out which one was into CFRG algorithms :-) ________________________________  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.

________________________________

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/