IETF Logo Mail Archive

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

"Rolf Lindemann" <rlindemann@noknok.com> Thu, 28 June 2018 09:45 UTC

Return-Path: <rlindemann@noknok.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 C5CE7130F37 for <jose-reg-review@ietfa.amsl.com>; Thu, 28 Jun 2018 02:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=noknok.com
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 XlhnbTKHIGg1 for <jose-reg-review@ietfa.amsl.com>; Thu, 28 Jun 2018 02:45:23 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B634A130F30 for <jose-reg-review@ietf.org>; Thu, 28 Jun 2018 02:45:22 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id 69-v6so8268075wmf.3 for <jose-reg-review@ietf.org>; Thu, 28 Jun 2018 02:45:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noknok.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=NO09psX0sZrJC+dhC5n8FMARuFBVYOTfYaS10A9PpBY=; b=OYXWMG3jzTZdVVFmEMUDhVV6OfuX9xqqpt/9/byxXrl/1n9rNJM68CgvKvNoQ8gs+d DffJRjG+1HQsdQiqCYn6NKt9qfru9tqk0twFdwstqPU9/MDbg4nDS8+XB9JzmJoO0W9f kvXoO5Swujt1hLZ3uJx641+Zu1e8VXhH1QAKg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=NO09psX0sZrJC+dhC5n8FMARuFBVYOTfYaS10A9PpBY=; b=dc53v4cYEnwhBLh16StqlxonH61WJNhxfMnbLGHXROhYA54oJI/G8QUrxk0pZItnSd n9Wl1OajrL3o9J+uadw0qWVmqCwKk0iuLWYCHWar7wHA28faV3OuarmhpRFvoe1bfIEV lF2Djt5iYGsydui5O9SVilbzxnGbLYr5xyZK2Na6RBmy7qd2LKXXwkaah/4OVkJiFe6K UaLPd8fIOJ6Tj9jDra/QbKxl6XD5WErxbr+BqPgI765tJAXAElBnETx9/aXeQ7SYXzc/ I3DwUw2aS6GASbNAADvJRGH7JfuTMjvX55GCAwYFH7gaHQ04uwFOgO1/o0xqXGRjEQYJ hWTQ==
X-Gm-Message-State: APt69E2z9Deu1d8+Zuu5D+4VDGTJ1BrfOYlxQuqVhFb7p6sC28/uSwL1 kChAzqJdyBwkv4URukC26rCm
X-Google-Smtp-Source: AAOMgpexe89jKYTWVgzUcrBQA3482G/BcIeWq08Zcf8zEFcZpJz2wH2D02aPtYGrRBjtvRJ/aV2akA==
X-Received: by 2002:a1c:a8a:: with SMTP id 132-v6mr7905383wmk.44.1530179120965; Thu, 28 Jun 2018 02:45:20 -0700 (PDT)
Received: from Myra (p2E54D01A.dip0.t-ipconnect.de. [46.84.208.26]) by smtp.gmail.com with ESMTPSA id n71-v6sm11110223wmi.14.2018.06.28.02.45.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jun 2018 02:45:19 -0700 (PDT)
From: Rolf Lindemann <rlindemann@noknok.com>
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>
References: <0ab801d3f9ce$40d7cca0$c28765e0$@noknok.com> <00b601d3f9e6$a3928840$eab798c0$@augustcellars.com> <0b9501d3f9f1$d8aa7280$89ff5780$@noknok.com> <044001d4026a$c64de690$52e9b3b0$@augustcellars.com>
In-Reply-To: <044001d4026a$c64de690$52e9b3b0$@augustcellars.com>
Date: Thu, 28 Jun 2018 11:45:18 +0200
Message-ID: <00d501d40ec4$ba033be0$2e09b3a0$@noknok.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01D40ED5.7D8E7CE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGeHCvjivkU/KJfI12hng9o59W1hwHTHdwiAVBOYikBl6c25KS7dQEw
Content-Language: de
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose-reg-review/55JfoZE43WHCUyqQeQmrPRu3lEw>
X-Mailman-Approved-At: Thu, 28 Jun 2018 09:48:32 -0700
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: Thu, 28 Jun 2018 09:45:27 -0000

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?

 

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.

 

Kind regards,

   Rolf

 

Von: Jim Schaad [mailto:ietf@augustcellars.com] 
Gesendet: Dienstag, 12. Juni 2018 18:31
An: rolf@noknok.com; jose-reg-review@ietf.org
Cc: jca@zurich.ibm.com; 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> 
Sent: Friday, June 1, 2018 2:45 PM
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

 

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; jose-reg-review@ietf.org
Cc: jca@zurich.ibm.com; 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> On Behalf Of Rolf
Lindemann
Sent: Friday, June 1, 2018 10:31 AM
To: jose-reg-review@ietf.org
Cc: jca@zurich.ibm.com; mbj@microsoft.com; 'Hodges, Jeff'
<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

v2.23.0 | Report a Bug | By Email