Re: [stir] Second WG Last Call for RFC4474bis

Russ Housley <housley@vigilsec.com> Thu, 15 September 2016 16:11 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A8E12BB84 for <stir@ietfa.amsl.com>; Thu, 15 Sep 2016 09:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 ISW-Zfvc8yoi for <stir@ietfa.amsl.com>; Thu, 15 Sep 2016 09:11:38 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1497312BE16 for <stir@ietf.org>; Thu, 15 Sep 2016 08:11:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 32FC6300A06 for <stir@ietf.org>; Thu, 15 Sep 2016 11:11:57 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Eb_zb2C3b_Lz for <stir@ietf.org>; Thu, 15 Sep 2016 11:11:56 -0400 (EDT)
Received: from 132-177-252-228.ip.sipit.net (unknown [132.177.252.228]) by mail.smeinc.net (Postfix) with ESMTPSA id 49094300446 for <stir@ietf.org>; Thu, 15 Sep 2016 11:11:56 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com>
Date: Thu, 15 Sep 2016 11:11:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED452CA4-ED21-42F3-A3F0-31BD37B77036@vigilsec.com>
References: <C1E751BC-55E9-4D8C-A6A5-B5674835870E@vigilsec.com> <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com>
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/-8AAZn_We5_pTI3Heh_PTSvGCKw>
Subject: Re: [stir] Second WG Last Call for RFC4474bis
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Sep 2016 16:11:46 -0000

I was talking to several implementers during SIPit32.  There was some surprise that JOSE and PKIX have specified different syntax for an ECDSA signature value.  I suggest that we include a warning about this in at least one of the documents.  I am not totally sure that 4474bis is the best place, and I’m pleased to let the authors select the best location or locations.  I propose some text below.

Russ

= = = = = = = =

Implementation Considerations

   An ECDSA signature is comprised of two values, called r and s.  These
   signatures are represented in two different ways in PASSporT and
   certificates.  PASSport signature values follow the conventions
   specified in JSON Web Algorithms (JWA) [RFC7518], where r and s are
   concatenated without any stripping or padding.  Since r and s are
   always the same length, dividing the signature value in half will
   recover the r and s values.  Certificate signature values follow the
   conventions in [RFC3279], where the r and s are ASN.1-encoded as a
   SEQUENCE of two non-negative integer values.  If the high order bit
   is set, then a zero octet is prepended to produce a positive integer
   value.  Recovery of the r and s values requires the removal of the
   added zero octet.