Re: [Jose-reg-review] Request to register JOSE algorithms for the FIDO Alliance

Jim Schaad <ietf@augustcellars.com> Fri, 29 June 2018 19:08 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: jose-reg-review@ietfa.amsl.com
Delivered-To: jose-reg-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DF4130E85 for <jose-reg-review@ietfa.amsl.com>; Fri, 29 Jun 2018 12:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIW2k2urjYpW for <jose-reg-review@ietfa.amsl.com>; Fri, 29 Jun 2018 12:08:16 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F253D130F33 for <jose-reg-review@ietf.org>; Fri, 29 Jun 2018 12:08:15 -0700 (PDT)
Received: from Jude (104.129.192.187) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 29 Jun 2018 12:04:05 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Rolf Lindemann' <rlindemann@noknok.com>, rolf@noknok.com, jose-reg-review@ietf.org
CC: jca@zurich.ibm.com, mbj@microsoft.com, "'Hodges, Jeff'" <jeff.hodges@paypal.com>
References: <0ab801d3f9ce$40d7cca0$c28765e0$@noknok.com> <00b601d3f9e6$a3928840$eab798c0$@augustcellars.com> <0b9501d3f9f1$d8aa7280$89ff5780$@noknok.com> <044001d4026a$c64de690$52e9b3b0$@augustcellars.com> <00d501d40ec4$ba033be0$2e09b3a0$@noknok.com>
In-Reply-To: <00d501d40ec4$ba033be0$2e09b3a0$@noknok.com>
Date: Fri, 29 Jun 2018 12:06:38 -0700
Message-ID: <028501d40fdc$611e3b60$235ab220$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0286_01D40FA1.B4C11110"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQGeHCvjivkU/KJfI12hng9o59W1hwHTHdwiAVBOYikBl6c25AIbSxG2pKwk2UA=
X-Originating-IP: [104.129.192.187]
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose-reg-review/Mzhdgouc9f2IO--_RmKfNsnlWZs>
Subject: Re: [Jose-reg-review] Request to register JOSE algorithms for the FIDO Alliance
X-BeenThere: jose-reg-review@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "The JSON Web Algorithm standard \(RFC 7518\) establishes this email list for designated experts to discuss proposed changes, additions, and removals to the set of algorithms in the JSON Object Signing and Encryption \(JOSE\) registry, http://www.iana.org/assignments/jose." <jose-reg-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose-reg-review>, <mailto:jose-reg-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose-reg-review/>
List-Post: <mailto:jose-reg-review@ietf.org>
List-Help: <mailto:jose-reg-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose-reg-review>, <mailto:jose-reg-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2018 19:08:23 -0000

 

 

From: Rolf Lindemann <rlindemann@noknok.com> 
Sent: Thursday, June 28, 2018 11:45 AM
To: 'Jim Schaad' <ietf@augustcellars.com>; rolf@noknok.com;
jose-reg-review@ietf.org
Cc: jca@zurich.ibm.com; mbj@microsoft.com; 'Hodges, Jeff'
<jeff.hodges@paypal.com>
Subject: AW: [Jose-reg-review] Request to register JOSE algorithms for the
FIDO Alliance

 

Hi Jim,

 

Regarding your first question:

> One of the things that I would like to see would be the definition of a
key structure as well. 

I guess you are referring to the structure of the public keys (only).  Is
that correct?

In the referenced document (i.e.
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#object-encodings), we define algorithms to encode the
keys (e.g. ECPoint2ToB, ECPointToB).  The ECDAA issuer public keys consist
of two values (typically denoted as X and Y) both of type ECPoint2 and hence
would be serialized/encoded according to the definition of ECPoint2ToB.

Is this what you are looking for?

 

[JLS] I am looking for a JOSE key structure which would require defining a
couple of things.  While I realize that you don't need it, it might also be
useful to have the private key fields defined as well for the purposes of
doing things like writing test cases such I have at
https://github.com/jimsch/Examples.git You might have a good case for not
needing one, but I would like to here what it is in that case.

 

 

 

Regarding your second question:

> I would like to verify that there is a requirement that the key size and
hash size are combined together as a fixed pair and not uncoupled as done
with the ECDSA algorithms where any sized key structure can be used with a
specific hash and applications can be further restrictions as necessary.  If
this is not the case, should the key set be made explicit rather than
implicit in the algorithm name?

 

Yes, hash algorithm and signature algorithm are paired.  So we specify the
following:

a.	ED256: FIDO ECDAA algorithm based on TPM_ECC_BN_P256 [TPMv2-Part4]
curve using SHA256 hash algorithm.
b.	ED512: ECDAA algorithm based on ECC_BN_ISOP512 [ISO15946-5] curve
using SHA512 algorithm.
c.	ED638: ECDAA algorithm based on TPM_ECC_BN_P638 [TPMv2-Part4] curve
using SHA512 algorithm.
d.	ED256-2: ECDAA algorithm based on ECC_BN_DSD_P256
(https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#bib-DevScoDah2007) curve using SHA256 algorithm.

 

[JLS] Reading my last sentence, I see that I got my text backwards.  Should
the Curve be part of the name rather than implicit so that there would be no
mistakes.  The use of ED256-2 seems to be an odd name that does not
necessarily provide good information.

 

Jim

 

 

Kind regards,

   Rolf

 

Von: Jim Schaad [mailto:ietf@augustcellars.com] 
Gesendet: Dienstag, 12. Juni 2018 18:31
An: rolf@noknok.com <mailto:rolf@noknok.com> ; jose-reg-review@ietf.org
<mailto:jose-reg-review@ietf.org> 
Cc: jca@zurich.ibm.com <mailto:jca@zurich.ibm.com> ; mbj@microsoft.com
<mailto:mbj@microsoft.com> ; 'Hodges, Jeff'
Betreff: RE: [Jose-reg-review] Request to register JOSE algorithms for the
FIDO Alliance

 

Sorry about the delay, I got pulled into some other work and forgot that I
had not sent a message.

 

One of the things that I would like to see would be the definition of a key
structure as well.  I don't believe that you can use any of the current ones
based on how things work.  Think about people who would use this algorithm
in other protocols and need to transfer the root of trust as well.

 

I would like to verify that there is a requirement that the key size and
hash size are combined together as a fixed pair and not uncoupled as done
with the ECDSA algorithms where any sized key structure can be used with a
specific hash and applications can be further restrictions as necessary.  If
this is not the case, should the key set be made explicit rather than
implicit in the algorithm name?

 

 

 

From: Rolf Lindemann <rlindemann@noknok.com <mailto:rlindemann@noknok.com> >

Sent: Friday, June 1, 2018 2:45 PM
To: 'Jim Schaad' <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >;
rolf@noknok.com <mailto:rolf@noknok.com> ; jose-reg-review@ietf.org
<mailto:jose-reg-review@ietf.org> 
Cc: jca@zurich.ibm.com <mailto:jca@zurich.ibm.com> ; mbj@microsoft.com
<mailto:mbj@microsoft.com> ; 'Hodges, Jeff' <jeff.hodges@paypal.com
<mailto:jeff.hodges@paypal.com> >
Subject: AW: [Jose-reg-review] Request to register JOSE algorithms for the
FIDO Alliance

 

Please see https://eprint.iacr.org/2015/1246 for that.

 

That is the reference included in the IANA considerations section of the
document (see
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#iana-considerations>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#iana-considerations)

 

Von: Jim Schaad [mailto:ietf@augustcellars.com] 
Gesendet: Freitag, 1. Juni 2018 22:25
An: rolf@noknok.com <mailto:rolf@noknok.com> ; jose-reg-review@ietf.org
<mailto:jose-reg-review@ietf.org> 
Cc: jca@zurich.ibm.com <mailto:jca@zurich.ibm.com> ; mbj@microsoft.com
<mailto:mbj@microsoft.com> ; 'Hodges, Jeff'
Betreff: RE: [Jose-reg-review] Request to register JOSE algorithms for the
FIDO Alliance

 

Are there any crypto analysis papers that I can peruse in case I am
interested?

 

From: Jose-reg-review <jose-reg-review-bounces@ietf.org
<mailto:jose-reg-review-bounces@ietf.org> > On Behalf Of Rolf Lindemann
Sent: Friday, June 1, 2018 10:31 AM
To: jose-reg-review@ietf.org <mailto:jose-reg-review@ietf.org> 
Cc: jca@zurich.ibm.com <mailto:jca@zurich.ibm.com> ; mbj@microsoft.com
<mailto:mbj@microsoft.com> ; 'Hodges, Jeff' <jeff.hodges@paypal.com
<mailto:jeff.hodges@paypal.com> >
Subject: [Jose-reg-review] Request to register JOSE algorithms for the FIDO
Alliance

 

Hi,

 

The FIDO Alliance would like to register the following algorithms in the
IANA "JSON Web Signature and Encryption Algorithms" registry:

1. "ED256", see
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#iana-considerations>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#iana-considerations

2. "ED512", see
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#iana-considerations>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#iana-considerations

3. "ED638", see
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#iana-considerations>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#iana-considerations

4. "ED256-2", 

    - Name "ED256-2"

    - Algorithm Description: ECDAA algorithm based on ECC_BN_DSD_P256 (
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#bib-DevScoDah2007>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#bib-DevScoDah2007) curve using SHA256 algorithm.

    - Algorithm Usage Locations: "alg", i.e. used with JWS.

    - JOSE Implementation Requirements: optional

    - Change Controller: FIDO Alliance,  <https://fidoalliance.org/contact/>
https://fidoalliance.org/contact/ 

    - Sections 3. FIDO ECDAA Attestation (
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#fido-ecdaa-attestation>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#fido-ecdaa-attestation) and 4. FIDO ECDAA Object Formats
and Algorithm Details (
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#fido-ecdaa-object-formats-and-algorithm-details>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#fido-ecdaa-object-formats-and-algorithm-details) of
[FIDOEcdaaAlgorithm].

    - Algorithm Analysis Document(s):
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#bib-FIDO-DAA-Security-Proof>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#bib-FIDO-DAA-Security-Proof 

("ED256-2" should have also been in the IANA Considerations section but
isn't due to a clerical error.)

 

These names are related to cryptographic algorithms for Direct Anonymous
Attestation.  The relevant details are described in
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v
2.0-id-20180227.html#iana-considerations>
https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2
.0-id-20180227.html#iana-considerations. 

The algorithms were developed by Jan Camenisch of IBM (cc'ed) - a
cryptographic expert.  They are in production use in FIDO deployments.

 

Kind regards,

     Rolf Lindemann