IETF Logo Mail Archive

Re: [Trans] duplicate 0x0403 in signature scheme registry

Benjamin Kaduk <kaduk@mit.edu> Tue, 30 March 2021 17:11 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7FA3A1B5E; Tue, 30 Mar 2021 10:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 CvbQzVYrdv1D; Tue, 30 Mar 2021 10:11:08 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B5E3A1B68; Tue, 30 Mar 2021 10:11:07 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12UHB0oF015014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Mar 2021 13:11:05 -0400
Date: Tue, 30 Mar 2021 10:11:00 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Rob Stradling <rob@sectigo.com>, "trans@ietf.org" <trans@ietf.org>
Message-ID: <20210330171100.GC79563@kduck.mit.edu>
References: <1E0248E8-A269-4C00-A0CA-60D4F89639A4@akamai.com> <MW3PR17MB4122D493F93E58FB545ECA3AAA7E9@MW3PR17MB4122.namprd17.prod.outlook.com> <7FEA0790-F768-487C-A08F-F0151DCE8150@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7FEA0790-F768-487C-A08F-F0151DCE8150@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/dDfiaO2kEaifK5gbdRDnGPEmmwk>
Subject: Re: [Trans] duplicate 0x0403 in signature scheme registry
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 17:11:13 -0000

On Tue, Mar 30, 2021 at 04:55:07PM +0000, Salz, Rich wrote:
> >> The duplicate 0x0403 seems a bug. Any implementor care to clarify
> 
> 
>   *   The duplicate 0x0403 is deliberate, because Deterministic and Non-Deterministic ECDSA have different References (RFC6979 and FIPS186-4).
> 
> How does a relying party know which one is actually being used?  (I am sure I am missing something obvious.)

The verifier procedures are the same for both, and the verifier can't tell
which one was used by the signer (unless the signer really screwed up and
used a non-random k).

-Ben

> > As for why this registry, I assume it’s to be a subset of the TLS registry “just because”  Are there any other reasons?
> 
> Yes, this was re-wording Mirja’s question. I understand the reasoning; is it worth putting something into the draft?
> 
> 
> 

> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans

v2.23.0 | Report a Bug | By Email