From rlindemann@noknok.com Fri Jun 1 10:30:39 2018 Return-Path: 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 A63DB12DA02 for ; Fri, 1 Jun 2018 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 5xX7mvNThhaH for ; Fri, 1 Jun 2018 10:30:37 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 5CFF612D9FF for ; Fri, 1 Jun 2018 10:30:37 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 185-v6so20442829qkk.11 for ; Fri, 01 Jun 2018 10:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noknok.com; s=google; h=reply-to:from:to:cc:subject:date:organization:message-id :mime-version:thread-index:content-language; bh=7//b8vLgWuOnuKaAK/mHoYnIY58vPCfc5xxZtwWvHdM=; b=GR4GI+KtsRguEfuGUy2HuEzUgBqw8gDRFWuWnU401TuYFKFXlNtP7+8UNzmqELnFeF 5DsJT5jKPtitwSyqSXwCoJiHH0sbcpF3tgytkrWCNnIuzWsKLWLGrT7oXPPodkTtEkEG 8ve0dwc+h7OTUxBOt0HeLqrBOLagP+H5g+ej0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:from:to:cc:subject:date:organization :message-id:mime-version:thread-index:content-language; bh=7//b8vLgWuOnuKaAK/mHoYnIY58vPCfc5xxZtwWvHdM=; b=jtlDuq2R8e2BmEAhEoLoSNz+/VOIQpaOyPJZOdelX5Wk2+4NYpEmjfAmM9fQGvi0T3 UqN5tiQuJ+HTZIW601D//rwRMyALPtF0w+HfOuiOKtuJFjwvcG56IKwZK6H8UlKCuhBg N5uy22HTk/4ZEtoDFoAtkk9MU8d0q+6IwIlR76gj9s8Ej91L4tEgwAHc7nwubSa3K5sK wpxN5TSj33ISdPeeMdmqyGmMiSQYcH7jxK0vUyfNa79pUXXNJIfyoegiI/aJWKoiRXf8 lwgNCc+RZ8edOTEDd8CfcYHShE+9XIdJDT/v70OHhOqPMtbBNGbD+MlPESukkD2rXFqS b0pw== X-Gm-Message-State: APt69E2upm4mFEqIPSLUULH0uiJCzgd9+8bMSSY/0bg1LKxer6QMiTSd kIHzFnXlZakGpofBKiF5dXHl X-Google-Smtp-Source: ADUXVKL/SS8UhUFDkK2+TBEdrFzRL3PPkmmvQyIvR1ZMQ+GOxasjAX7g8jFORlYK81gLoTGa4MI2Gw== X-Received: by 2002:a37:c949:: with SMTP id q70-v6mr10816761qki.174.1527874236276; Fri, 01 Jun 2018 10:30:36 -0700 (PDT) Received: from Myra (198-27-138-18.static.sonic.net. [198.27.138.18]) by smtp.gmail.com with ESMTPSA id f8-v6sm7100587qkm.42.2018.06.01.10.30.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 10:30:35 -0700 (PDT) Reply-To: From: "Rolf Lindemann" To: Cc: , , "'Hodges, Jeff'" Date: Fri, 1 Jun 2018 19:30:35 +0200 Organization: Nok Nok Labs Message-ID: <0ab801d3f9ce$40d7cca0$c28765e0$@noknok.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AB9_01D3F9DF.04655790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdP5OpIcc678paA9S/GwU/X8TbmHeg== Content-Language: de Archived-At: Subject: [Jose-reg-review] Request to register JOSE algorithms for the FIDO Alliance X-BeenThere: jose-reg-review@ietf.org X-Mailman-Version: 2.1.22 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:31:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0AB9_01D3F9DF.04655790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-v2 .0-id-20180227.html#iana-considerations 2. "ED512", see 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-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-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/ - Sections 3. 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-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-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-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 ------=_NextPart_000_0AB9_01D3F9DF.04655790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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-v2.0-id-20180227.html#ia= na-considerations

2. "ED512", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-considerations

3. "ED638", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#bi= b-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/

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

    - Algorithm Analysis Document(s): https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#bi= b-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-v2.0-id-20180227.html#ia= na-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

------=_NextPart_000_0AB9_01D3F9DF.04655790-- From nobody Fri Jun 1 13:25:20 2018 Return-Path: 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 0E2A412DA14 for ; Fri, 1 Jun 2018 13:25:19 -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 vihS8MajQWGL for ; Fri, 1 Jun 2018 13:25: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 0F4561205F0 for ; Fri, 1 Jun 2018 13:25:15 -0700 (PDT) Received: from Jude (192.168.1.166) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 1 Jun 2018 13:22:22 -0700 From: Jim Schaad To: , CC: , , "'Hodges, Jeff'" References: <0ab801d3f9ce$40d7cca0$c28765e0$@noknok.com> In-Reply-To: <0ab801d3f9ce$40d7cca0$c28765e0$@noknok.com> Date: Fri, 1 Jun 2018 13:25:05 -0700 Message-ID: <00b601d3f9e6$a3928840$eab798c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01D3F9AB.F7347390" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGeHCvjivkU/KJfI12hng9o59W1h6S3lMMA Content-Language: en-us X-Originating-IP: [192.168.1.166] Archived-At: 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.22 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 20:25:19 -0000 ------=_NextPart_000_00B7_01D3F9AB.F7347390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Are there any crypto analysis papers that I can peruse in case I am interested? From: Jose-reg-review 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' 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-v2 .0-id-20180227.html#iana-considerations 2. "ED512", see 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-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-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/ - Sections 3. 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-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-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-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 ------=_NextPart_000_00B7_01D3F9AB.F7347390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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-v2.0-id-20180227.html#ia= na-considerations

2. = "ED512", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-considerations

3. = "ED638", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#bi= b-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/

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

    - Algorithm Analysis = Document(s): https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#bi= b-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-v2.0-id-20180227.html#ia= na-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

------=_NextPart_000_00B7_01D3F9AB.F7347390-- From nobody Fri Jun 1 14:45:28 2018 Return-Path: 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 528A812DA1C for ; Fri, 1 Jun 2018 14:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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] 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 3ttdvmU7gaAf for ; Fri, 1 Jun 2018 14:45:24 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 4FFCD12DA4C for ; Fri, 1 Jun 2018 14:45:24 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id e8-v6so33993294qth.0 for ; Fri, 01 Jun 2018 14:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noknok.com; s=google; h=reply-to:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:thread-index:content-language; bh=iLyv8mxC7OdjQc5nsa+bx+SSQWTbw5AhpsUw4EEh6V4=; b=aSXdHtaXUzBLecjHtH0WpGrgA6NJYH3VWIJFUh1H2Jgo6sjhfuLBnkChADTTbmaO39 MlzD1FHI6MKFdy01munoCQ+w1dcVuRFMXV095aTGoW/LJTWQz0jsFB1vsXGYcIuRV1w8 KBYQcs0NlKwrQIXQBEk78m3Ip9tP3+EnSO0o4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version:thread-index :content-language; bh=iLyv8mxC7OdjQc5nsa+bx+SSQWTbw5AhpsUw4EEh6V4=; b=S1PIn+0k5sWQCeACDv64NW+rPnwa3I/m+CDOW0ufvAyApcZGE2GkNL5NFhKUMO4TFC NU0wp8FFycquJQYqK5Do1w3liiQtR3Ioulp/MYSGQc9McflOLGWOprnNzPHcOaMqb6gZ JxpVWVOuS/wkskH+K1NGMoVA56RKP7wIY6OQ1sQx9bp/Uu8fJlw6D06MgqzTzFeAvNPn 9Fq3IMaBAcW7dcqpVNrnIII7CizqMv+ou5iBI1vrfbYQJ6yOJiLYD/wG8vJ21l34Txnx AnmSXOwa4z0SyvqhzxQZgpQQEM/Sz2VxMYXqOFFkKwBd9b54SKuoRp/I8zv8eQ3wk6aJ /eeQ== X-Gm-Message-State: APt69E0vwnlX+06BkON1Uo070Z/GlE7m+GUcDDNmtis55oEb5TNj8bQZ eBwDpdCG75ZZBcDvL6alafHd X-Google-Smtp-Source: ADUXVKIJDjYwRgtbbftdf+/dT2M6KMj1jyHSxyWYEJjmPB/UZmlSbFTfx/0OQSWO7/f8J1eUe9CDmQ== X-Received: by 2002:a0c:f64d:: with SMTP id s13-v6mr12307908qvm.105.1527889523251; Fri, 01 Jun 2018 14:45:23 -0700 (PDT) Received: from Myra ([216.9.109.60]) by smtp.gmail.com with ESMTPSA id e96-v6sm18444250qtb.69.2018.06.01.14.45.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 14:45:22 -0700 (PDT) Reply-To: From: "Rolf Lindemann" To: "'Jim Schaad'" , , Cc: , , "'Hodges, Jeff'" References: <0ab801d3f9ce$40d7cca0$c28765e0$@noknok.com> <00b601d3f9e6$a3928840$eab798c0$@augustcellars.com> In-Reply-To: <00b601d3f9e6$a3928840$eab798c0$@augustcellars.com> Date: Fri, 1 Jun 2018 23:45:20 +0200 Organization: Nok Nok Labs Message-ID: <0b9501d3f9f1$d8aa7280$89ff5780$@noknok.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B96_01D3FA02.9C395D00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGeHCvjivkU/KJfI12hng9o59W1hwHTHdwipKkSKvA= Content-Language: de Archived-At: 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.22 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 21:45:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B96_01D3FA02.9C395D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-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 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' 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-v2 .0-id-20180227.html#iana-considerations 2. "ED512", see 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-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-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/ - Sections 3. 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-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-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-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 ------=_NextPart_000_0B96_01D3FA02.9C395D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see https://eprint.iacr.org/2015/1= 246 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-v2.0-id-20180227.html#ia= na-considerations)

 

Von:<= /b> = 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-v2.0-id-20180227.html#ia= na-considerations

2. "ED512", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-considerations

3. "ED638", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#bi= b-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/

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

    - Algorithm Analysis Document(s): https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#bi= b-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-v2.0-id-20180227.html#ia= na-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

------=_NextPart_000_0B96_01D3FA02.9C395D00-- From nobody Tue Jun 12 09:31:27 2018 Return-Path: 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 41A21130E31 for ; Tue, 12 Jun 2018 09:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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, URIBL_BLOCKED=0.001] 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 ayx28AfXSiIU for ; Tue, 12 Jun 2018 09:31:17 -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 CB8BB12D949 for ; Tue, 12 Jun 2018 09:31:16 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 12 Jun 2018 09:28:16 -0700 From: Jim Schaad To: , CC: , , "'Hodges, Jeff'" References: <0ab801d3f9ce$40d7cca0$c28765e0$@noknok.com> <00b601d3f9e6$a3928840$eab798c0$@augustcellars.com> <0b9501d3f9f1$d8aa7280$89ff5780$@noknok.com> In-Reply-To: <0b9501d3f9f1$d8aa7280$89ff5780$@noknok.com> Date: Tue, 12 Jun 2018 09:31:08 -0700 Message-ID: <044001d4026a$c64de690$52e9b3b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0441_01D40230.19F02000" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGeHCvjivkU/KJfI12hng9o59W1hwHTHdwiAVBOYimkr4BakA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 16:31:24 -0000 ------=_NextPart_000_0441_01D40230.19F02000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 Sent: Friday, June 1, 2018 2:45 PM To: 'Jim Schaad' ; rolf@noknok.com; jose-reg-review@ietf.org Cc: jca@zurich.ibm.com; mbj@microsoft.com; 'Hodges, Jeff' 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-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 > 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' > 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-v2 .0-id-20180227.html#iana-considerations 2. "ED512", see 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-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-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/ - Sections 3. 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-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-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-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 ------=_NextPart_000_0441_01D40230.19F02000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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/1= 246 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-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#ia= na-considerations

2. = "ED512", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-considerations

3. = "ED638", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#bi= b-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/

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

    - Algorithm Analysis = Document(s): https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#bi= b-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-v2.0-id-20180227.html#ia= na-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

------=_NextPart_000_0441_01D40230.19F02000-- From nobody Thu Jun 28 09:48:32 2018 Return-Path: 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 ; 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 ; 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 ; Thu, 28 Jun 2018 02:45:22 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id 69-v6so8268075wmf.3 for ; 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" To: "'Jim Schaad'" , , Cc: , , "'Hodges, Jeff'" 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 09:45:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D6_01D40ED5.7D8E7CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 Sent: Friday, June 1, 2018 2:45 PM To: 'Jim Schaad' ; rolf@noknok.com; jose-reg-review@ietf.org Cc: jca@zurich.ibm.com; mbj@microsoft.com; 'Hodges, Jeff' 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-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 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' 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-v2 .0-id-20180227.html#iana-considerations 2. "ED512", see 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-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-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/ - Sections 3. 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-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-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-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 ------=_NextPart_000_00D6_01D40ED5.7D8E7CE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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#o= bject-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-algorith= m-v2.0-id-20180227.html#bib-DevScoDah2007) curve using SHA256 = algorithm.

 

Kind = regards,

   Rolf

 

Von:<= /b> = 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/1= 246 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-v2.0-id-20180227.html#ia= na-considerations)

 

Von:<= /b> = 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-v2.0-id-20180227.html#ia= na-considerations

2. "ED512", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-considerations

3. "ED638", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#bi= b-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/

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

    - Algorithm Analysis Document(s): https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#bi= b-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-v2.0-id-20180227.html#ia= na-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

------=_NextPart_000_00D6_01D40ED5.7D8E7CE0-- From nobody Fri Jun 29 12:08:27 2018 Return-Path: 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 ; 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 ; 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 ; 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 To: 'Rolf Lindemann' , , CC: , , "'Hodges, Jeff'" 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 19:08:23 -0000 ------=_NextPart_000_0286_01D40FA1.B4C11110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Rolf Lindemann Sent: Thursday, June 28, 2018 11:45 AM To: 'Jim Schaad' ; rolf@noknok.com; jose-reg-review@ietf.org Cc: jca@zurich.ibm.com; mbj@microsoft.com; 'Hodges, Jeff' 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 ; 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 > Sent: Friday, June 1, 2018 2:45 PM To: 'Jim Schaad' >; rolf@noknok.com ; jose-reg-review@ietf.org Cc: jca@zurich.ibm.com ; mbj@microsoft.com ; 'Hodges, Jeff' > 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-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 > 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' > 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-v2 .0-id-20180227.html#iana-considerations 2. "ED512", see 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-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-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/ - Sections 3. 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-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-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-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 ------=_NextPart_000_0286_01D40FA1.B4C11110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

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#o= bject-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:

  1. ED256: = FIDO ECDAA algorithm based on TPM_ECC_BN_P256 [TPMv2-Part4] curve using = SHA256 hash algorithm.
  2. ED512: = ECDAA algorithm based on ECC_BN_ISOP512 [ISO15946-5] curve using SHA512 = algorithm.
  3. ED638: = ECDAA algorithm based on TPM_ECC_BN_P638 [TPMv2-Part4] curve using = SHA512 algorithm.
  4. ED256-2: = ECDAA algorithm based on ECC_BN_DSD_P256 (https://fidoalliance.or= g/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.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; 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/1= 246 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-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#ia= na-considerations

2. = "ED512", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-considerations

3. = "ED638", see https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#ia= na-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-v2.0-id-20180227.html#bi= b-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/

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

    - Algorithm Analysis = Document(s): https://fidoalliance.org/= specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#bi= b-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-v2.0-id-20180227.html#ia= na-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

------=_NextPart_000_0286_01D40FA1.B4C11110--