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

Anders Kristensen <andersk@google.com> Sun, 02 October 2016 23:25 UTC

Return-Path: <andersk@google.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 7E2E312B0EE for <stir@ietfa.amsl.com>; Sun, 2 Oct 2016 16:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2s5v6fvku95x for <stir@ietfa.amsl.com>; Sun, 2 Oct 2016 16:25:29 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 8AFD4127A91 for <stir@ietf.org>; Sun, 2 Oct 2016 16:25:29 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id f193so77567510wmg.0 for <stir@ietf.org>; Sun, 02 Oct 2016 16:25:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=+hGpKP6xseJJAb8FS6GOgUuidu9fKQr1NsBOTmaIrd0=; b=llmgmbHpInnaRck869v4CWf98H3OXEkTgNA29dEZO2An74CN6nghTd3V/EU/JfNz7L uFB3nC3SCSwqJ9E0C0xudgwNWHbxEhEudUGSQJzuU83t6Pn2vWOT4N65+A13dvZ4LI0k c5/B2ddVkVevSPaW5SlUBPcF7dnBOMvYpoPycPfGHdlza2s+nM+50+ooldpWpfL/gHDO YeissDvHnfMhYlCFp/Cdinjyq3Hgo4lUlCPxKsW9gkdLOxmvSWauYW2SaHnmV/04llC9 /Ub/wyXbFEbQ0WcC7PFob23pHUv2haUdet+9b7vkVNrh5GI6AvqdbXsnzuhm3P43eV8t Rn3Q==
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=+hGpKP6xseJJAb8FS6GOgUuidu9fKQr1NsBOTmaIrd0=; b=PBI5FXAFAMs9cb2m6PqNN174USKfge6thIe+OZ9lyYbRsX2kGRdR+jr8GX4Qdwf2ti nDfUFA5GbYAfNAtqrEnOjwlQHx8zwWfRmck51rd7I3dOTIBwAN/XWj/z3FIYPiA0I80H a8l2RgZLafJuQ/zx5rtgN+FMpEWVKMjkUtY1LV7nfrPKr7Bx7JZ+pbPJbF+NJh1CJfVT XmzdoHka1yjoc38hjXfw5ZBvkkzujhAXYJ3USlxTxpYj6z4l5aHtWQUqUiU2RdpllyXA v/S5s2YGHamHPvQRFVL0r0ocNOuTESP/DaHi/zOaZ46zg9NallMffEimzgl7nXRjY/+z 72Sg==
X-Gm-Message-State: AA6/9RmLWZeu81uYr4e3bRf+2GzPs43wI0vcsTu687h+3y3oB+SSy1rrsIk2fODxtjVYYKdSha+GskO+Qw0UtMlw
X-Received: by 10.28.91.11 with SMTP id p11mr5925713wmb.98.1475450727621; Sun, 02 Oct 2016 16:25:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.109.67 with HTTP; Sun, 2 Oct 2016 16:25:26 -0700 (PDT)
From: Anders Kristensen <andersk@google.com>
Date: Sun, 02 Oct 2016 16:25:26 -0700
Message-ID: <CACG=0wTjS_-DZYyN=LkYxSw+Q1GYbv4w1DWmAbgrzmFJxt05HQ@mail.gmail.com>
To: stir@ietf.org
Content-Type: multipart/alternative; boundary="001a11497e1e81492d053dea2494"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/03rhG1cHy2SEXwYqW9zyR4L4U9c>
Subject: [stir] Comments on draft-ietf-stir-certificates-08
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: Sun, 02 Oct 2016 23:25:31 -0000

* 3: s/SubjectAltName/subjectAltName/ - for consistency if nothing else.

* 3: The first approach is to use subjectAltName and the second is to use
the TN Auth List defined in this doc. If one wanted to use SPID then
presumably the right way to do it would be to use the TN Auth List but the
text here talks about using SPID in subjectAltName. Probably shouldn't be
encouraged.

* 4:

   o  See Section 7
<https://tools.ietf.org/html/draft-ietf-stir-certificates-08#section-7>
for requirements related to the TN Query certificate
      extension.


Was this meant to refer to TNAuthorizationList rather than TNQuery?

* 7: My preference would be to not list support for SIP as mandatory for
info URIs. Using SUBSCRIBE/NOTIFY feels contrived and unnecessary.

* 7: OTOH using data: might make sense. Avoids cid: issue with
non-multipart support.

* 7: Re caching of certs, the doc could mention that a best practice is for
the server to never modify resources identified by info URIs, e.g. use cert
serial number rather than subjectAltName in the URI.

* 8: So TNAuthorizationList is List<List<TNEntry>>. Why can't it just be
List<TNEntry>?

* 8: I'm not sure if ServiceProviderIdentifierList is supposed to contain
SPID, Alt SPID and Last Alt SPID in that order. For example, if a cert
contains a TNEntry with a spid of length 2 then those two entries would be
expected to match SPID and Alt SPID of the calling number respectively?

* 9: s/all/call/

* 9.2: ISTM that if OCSP is always used to check freshness of TN auth lists
then the actual content of the list is irrelevant. The authority check has
just been delegated to the CA...

* 9.2: I guess OCSP is not really for the SPID case? If so, maybe mention.

* 9.3: s/list of TNs/calling number/ ?