Re: [stir] I-D Action: draft-ietf-stir-certificates-17.txt

Martin Thomson <martin.thomson@gmail.com> Fri, 15 December 2017 23:08 UTC

Return-Path: <martin.thomson@gmail.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 D669E1242EA for <stir@ietfa.amsl.com>; Fri, 15 Dec 2017 15:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3drTL2VCSZTN for <stir@ietfa.amsl.com>; Fri, 15 Dec 2017 15:08:33 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 7F9FF1241FC for <stir@ietf.org>; Fri, 15 Dec 2017 15:08:33 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id d27so9105501ote.11 for <stir@ietf.org>; Fri, 15 Dec 2017 15:08:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S6AFDww2YfRQE7z8nFWVryyuZg9GvuFdWDzcJ2PIsZE=; b=OdbDWsZ7A3CBGsar/obN2srMyl8cBqWUFrL5xNi1ydxbHZN7uC7pCjwXLeBZcnChY1 35tjUHp7dJmPHqyePz1V/eNZ6i8o2kLFdKGNbRRDio0RQb9AxHwFhe3RvgRoWvbabQrz GHlU5kwYDhI2pQajLBVE5AKg8hbv6R5nYuNtJaRhfRRfFnDcaSvBiDuxKV+XwjRKSa06 YpAd8IG6HrUIiYnZYSGumYCr3Yd54kM3gZLAmoPMZuML9/I86zfapS9IqJS031HmV8bz CwRm/uhRPlJUErh/yHJQVs/3uoATkiC+SHptq+TrAftLiokzzmDycGOZn4W7iImU5nNh rcKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S6AFDww2YfRQE7z8nFWVryyuZg9GvuFdWDzcJ2PIsZE=; b=mwm5/GfRhvc4Fl+kwHEmtv0MPBiP1DoltLuOoSVWRmQMzFgrn5cIi0MVwaURAV+mbq EXEbgY0xqI3P/xipf+7f16jNURzqi9823XpsHhrWay8PteYuNGW4RKFVyiv5LEt86JjO n0uPzr4QLgMOX/wWb/h+SBGyXUg46vOAPYjKivU9m4xA5lHWfiljBTdAMkOtJrTFmRqJ k0ZYvW4VRjAFF75VA4qAQllNlXV5Jiqu33GZ7OxrjEz+309NyF7uTLOY9IgEdfONI7f/ tcuYXNZv2aoivCg7TC0IV/4+fhlmAOVOEZi896YyTZJez34jDo+g/K0bpd+ME70c09Y6 N9zg==
X-Gm-Message-State: AKGB3mKGLBCGq4eUy+C9EjB84g+FkBrhtYz3/lQ0n3U+t48k33NyOP1Y YXu6x4U+yrCtGOtqjVpYjPoA/rzJwdmvYz9i/Dj1yTf+
X-Google-Smtp-Source: ACJfBotSV0sibTCwqrC2QZwHLzPd5CAtDrGtI4Ke+sNiMI3Ox1IZrg6MKSQ5kqj5DAIt78zVmLwWbQgjwLgz2Jt7ROU=
X-Received: by 10.157.32.19 with SMTP id n19mr9580310ota.133.1513379312804; Fri, 15 Dec 2017 15:08:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.8.11 with HTTP; Fri, 15 Dec 2017 15:08:31 -0800 (PST)
In-Reply-To: <333F2A6D-6CAF-4480-A448-06B76E1B397E@vigilsec.com>
References: <151326691971.6099.4107849780973461328@ietfa.amsl.com> <7E30739D-C21C-466E-8C3A-8395171C253D@sn3rd.com> <CABkgnnXCizOyLkJzSR-MHo97O2feOiGXfOVFZeQPoNzj4m452g@mail.gmail.com> <07AB7CB1-E5A2-45EE-B90E-B11E6A04C018@sn3rd.com> <1AF855C9-7129-4098-A137-2CF6099A3A1C@vigilsec.com> <c03d5092-5646-0807-3e16-864aeeb3e413@alum.mit.edu> <333F2A6D-6CAF-4480-A448-06B76E1B397E@vigilsec.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 15 Dec 2017 17:08:31 -0600
Message-ID: <CABkgnnXf01yfh2pfo+RqTjAfEr0KUGm1U=WFt0vHAZ=ScrWYHA@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, IETF STIR Mail List <stir@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/6aCW1FnTc6O3K4zdthiiA88FL6E>
Subject: Re: [stir] I-D Action: draft-ietf-stir-certificates-17.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 15 Dec 2017 23:08:35 -0000

On Fri, Dec 15, 2017 at 3:45 PM, Russ Housley <housley@vigilsec.com> wrote:
> To be clear, there is not a security issue here.  "123" + 900 and "123" + 876 specify the same block of numbers.  If a certificate issuer says "123" + 900, do we really want to reject the certificate as badly formed?

Yup.

> Does anyone have language to make "123" + 876 the preferred encoding?

OLD:
   count never
   makes the number increase in length (i.e., a TelephoneNumberRange
   with TelephoneNumber=10 with a count=91 will address numbers
   10-99); formally, given the inputs count and TelephoneNumber of
   length D the end of the TelephoneNumberRange is:
   MIN(TelephoneNumber + count, 10^D - 1).
NEW:
   count MUST NOT make the number increase in length (i.e., a
TelephoneNumberRange
   with TelephoneNumber=10 with a count=91 is invalid); formally,
given the inputs count and TelephoneNumber of
   length D TelephoneNumber + count MUST be less than 10^D.

That is, treat "123"+900 the same way you would a range with a
negative count "123"+(-10).