Re: [stir] Comments on draft-ietf-stir-certificates-09

"Drage, Keith (Nokia - GB)" <> Fri, 24 March 2017 21:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD861129987 for <>; Fri, 24 Mar 2017 14:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.697
X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fLCgxYd6wksN for <>; Fri, 24 Mar 2017 14:24:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EED2A12985F for <>; Fri, 24 Mar 2017 14:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WZlT3PAa9kOaG5OxS+B/GBwIy8I+LC/noZhHkLAKvGo=; b=Wq4Ggnjic5SEnAtbBWXJl/P40iOYxNgj5olBdZV9+60h26VoPH6UJkSnAh++nGeRj7kM7GW+fKfxB/UIAAZyLOlzSUqg5rDSQjgdSFHoUuA8vgdKmw01VUhdI/6ilZm0AeUayRvu62d+SiGX8aJo22SSpf2LqWMEDJ9bzUk90zk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 24 Mar 2017 21:24:43 +0000
Received: from ([fe80::f8ee:4cd:212f:cfc4]) by ([fe80::f8ee:4cd:212f:cfc4%14]) with mapi id 15.01.0991.018; Fri, 24 Mar 2017 21:24:43 +0000
From: "Drage, Keith (Nokia - GB)" <>
To: "" <>
Thread-Topic: [stir] Comments on draft-ietf-stir-certificates-09
Thread-Index: AQHSpCw9foJaLIRti02PDeIoEujZ8aGkgIAQ
Date: Fri, 24 Mar 2017 21:24:43 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; DB5PR07MB1478; 7:Ev/YDZVTdsnNuQnjHUfvfOApLSMgXl4Gc1HRH1NMGydvsXmdz2JJFySlV81bq19HrLN8I1qdatAj0kViU7S5QJyxBlXLNLM9CHBiCWsEhGig3XixnfJvkJflelAVAyZa2R/ZPf8KxLVywBZhbWfExAbF9hDVnJ8FkJUy1E9qWrmCNem+Rj6/hRiR9l05jGn08RkQQv/9PpMEVx+rancPXOxanVqffr0mbaJLynOfluFojJz74x1mo/5AtIVkNXpDaWLttjoEPYUfkqmaqZbDKbx7ORp0Dya3JrB2i+y90fFtJVVZr6ywVFaiaDPj1J6JS0Wyz4Y19A0IRqnBAAI96g==
x-ms-office365-filtering-correlation-id: f95b2033-0028-463a-a068-08d472fc3060
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DB5PR07MB1478;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(35073007944872)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DB5PR07MB1478; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1478;
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(2501003)(3660700001)(6306002)(6506006)(54896002)(66066001)(74316002)(7736002)(5640700003)(55016002)(99286003)(7696004)(3846002)(6116002)(3280700002)(25786009)(53546009)(6916009)(790700001)(2950100002)(9686003)(5660300001)(6436002)(5250100002)(54356999)(229853002)(102836003)(50986999)(189998001)(76176999)(5630700001)(2906002)(86362001)(110136004)(38730400002)(6246003)(53936002)(33656002)(230783001)(2900100001)(2351001)(81166006)(8936002)(1730700003)(8676002)(561924002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1478;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR07MB148045481C302C7BDFAFE54EF73E0DB5PR07MB1480eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 21:24:43.2334 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1478
Archived-At: <>
Subject: Re: [stir] Comments on draft-ietf-stir-certificates-09
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Mar 2017 21:24:49 -0000

I’d note that I am not aware of any standard that defines that telephone numbers have a sequence. Further it should be remembered that it is convention in some countries only that telephone numbers might have a fixed length from a common root.

Therefore rather than talking about a block or a range of numbers, it would be better to talk about numbers with a common set of most significate digits, with posibly the next digit being a subset of the full digits 0 through 9, and so on.



From: stir [] On Behalf Of Eric Rescorla
Sent: 23 March 2017 23:20
Subject: Re: [stir] Comments on draft-ietf-stir-certificates-09

You don't define the semantics of TelephoneNumberRange. This seems
like it's potentially subtle. The natural design seems like you
would interpret start as if it were an integer and then allow
everything in the range [start, start + count ). However, aren't
there edge cases here. Consider the field that contains:

  { +1.999.999.9999, 2 }  // punctuation added for clarity.

Clearly, +1.999.999.9999 is permitted, but are there any other
numbers permitted? My algorithm above would include
+, but that's clearly not right. Does it wrap
so that it includes + Seems like some text
is required here.

In reading -12, this does not seem to be adjusted :)


S 10.
   The tradeoff between short lived certificates and using status
   information is that the former’s burden is on the front end (i.e.,
   enrollment) and the latter’s burden is on the back end (i.e.,
   verification).  Both impact call setup time, but it is assumed that
   generating a short-lived certificate for each call, and consequently
   performing enrollment for each call, is more of an impact than
   acquiring status information.

This seems to confuse enrollment with certificate issuance. However,
at least in protocols like ACME, that's not correct: you enroll
once and then you can get as many certs issued as you want within
a time window. It's not clear why this would be a bigger issue
than OCSP, and there are obvious latency advantages because you
can get a new cert at the start of dialing (i.e., before the
destination number is known).

You are also ignoring the possibility of OCSP stapling, which
would seem to resolve both concerns. It seems like it would
be good to specify this mode.

S 10.2.
   The requirement to consult OCSP in real time results in a network
   round-trip time of day,

Should this say "delay"?

S 10.2.1.
Am I supposed to be getting here that you are importing a bunch of
the HVE requirements, but you don't want to directly refer to HVE
because of the requirement to not use per-request extensions. Is
that right? If so, maybe it would be better to normatively reference
the spec and then override it.

S 10.3.
How does the mechanism described in this section interact with TN
lists that are in the cert? Or do you only use it if you have the
spid form?