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

Eric Rescorla <ekr@rtfm.com> Sat, 29 October 2016 11:04 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EC90D1295CC for <stir@ietfa.amsl.com>; Sat, 29 Oct 2016 04:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id G0Id0-2P_iDB for <stir@ietfa.amsl.com>; Sat, 29 Oct 2016 04:04:49 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 8A1E61295CA for <stir@ietf.org>; Sat, 29 Oct 2016 04:04:49 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id 205so29052414ybz.3 for <stir@ietf.org>; Sat, 29 Oct 2016 04:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=nzkW40+wexat/NFbZN/itCk26Btv43Tbc8M7ga6WNGc=; b=q6Y6eoGSGXrYWtDD8RaT+Wog8SJWNWWGD3Sw2Rkj7MlEiL71EqG1Z+tqiAB2jwj6n2 M5pZALmwj9Uy+zlgJLU714kXH+pWthis/RNvncBEf0rgs1OxegJ+97S3hOYMy72MPwOz kzJpVqGFjW4jZJ/OEHt5mLhENthCMb+MBmH700KK78uj3q/T6hLhLT0v0rz/M/HfYwA2 NZOFmyZjj9+nnThr4IWlGdDV2Q/9Z8cJjto5VD0zgeqjxh76d/BMo7bdsPy7ZUphZ8EQ PkD/POthPWar6U63dRhfRi7OO+EnbgkHhUiT5xYmIRYtR/53kcurAdO47qi6UjvmMCKj 8mIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nzkW40+wexat/NFbZN/itCk26Btv43Tbc8M7ga6WNGc=; b=L3ctsC3EUi/GJyaicRa8BSv2ZlVdRHFJF46GYfx69so0N3uB26pxDhjA90Gn+L98u/ RxSXvsXnlQBfNcHPj0KefbgoUU91Q2DEIm5fHkmajYnNY1IimKt0CZCc2TrxbRL4dpHs 4KuzYoI5wj90dBbASvz2UQ83BuJlm+1eVOIdIMBcuU+TgQRzRTw/RTi8OtJmVYNOJc0H GmYTucBsjWBOCFZ72xreL3GaO6X8emCkGua/72tv8zuVVCZ1yvVX1Ue9IUbG+p6cJhEQ 6qJkLP5y5DNxb3aKddiPNeUQ9/Yzcv0vcDsD5TiuCK9GjSdAuVo6tPw3UDYYhGGXEsZf eaHw==
X-Gm-Message-State: ABUngvcmZsnr/2h+BEH42zl5KWNZfeQ8jXJfLlQJPODd1ej24vj4MiKUvs1bk+GDvYY92qZk3FjV7ZkaN3/tIg==
X-Received: by with SMTP id v70mr15026173ybi.80.1477739088583; Sat, 29 Oct 2016 04:04:48 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 29 Oct 2016 04:04:08 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 29 Oct 2016 22:04:08 +1100
Message-ID: <CABcZeBOZskcOXD9ObFarcyy14G_Kfh7YoarESHE7GFxdvwtbpw@mail.gmail.com>
To: "stir@ietf.org" <stir@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0921127263a5053ffef188"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/qDaIQ8tDm9R4kRAtoDp0fJOlOa4>
Subject: [stir] Comments on draft-ietf-stir-certificates-09
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: Sat, 29 Oct 2016 11:04:51 -0000

This sees like it's pretty sound, but there are several points that
seem like they need some work.

S 5.1.
NIT: "A CAs" -> "A CA"

S 6.
The last graf on this kind of comes out of left field and seems
like an operational issue. I can think of a lot of different ways
you might disseminate keys, and I suspect that people almost
never use signed PKCS#8

S 7.
You need a better reference here for what it is people are
being asked to implement in RFC 7030. It appears that you would
want to require the ability to get the originator's certificates
at the verifier, but requiring SCET for enrollment is not really what
we want. Probably ACME is what we want.

S 9.
Why bother with the E164Number branch. You already have a range
version, so you could just have range of one.

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.

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?