Re: [stir] Second WG Last Call for RFC4474bis

Mary Barnes <mary.ietf.barnes@gmail.com> Thu, 22 September 2016 19:16 UTC

Return-Path: <mary.ietf.barnes@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 DB5D612D611 for <stir@ietfa.amsl.com>; Thu, 22 Sep 2016 12:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 AVpUEPU3B7uZ for <stir@ietfa.amsl.com>; Thu, 22 Sep 2016 12:16:54 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 3D90512D61F for <stir@ietf.org>; Thu, 22 Sep 2016 12:16:54 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id t83so109382263oie.3 for <stir@ietf.org>; Thu, 22 Sep 2016 12:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cdwd52xMOEsts33nPTq3Yie0Cs+8iOghkZXQ65+/Yes=; b=T3PUffv7VvzxmQJVnLF5VZ4hMcu1aa5sd0CO4s9YkZQZ1MVO3l1f4Uh0ig131f8Hjv 6JeRk5FX5WyeV9M5BOx6MJfV6QnHqaWcJGmWZna5a963UA3D7UWdR9CJASC/7NpHF6+B wvJaISd0l7lZtI49RmAUsrzMc5HkR6DJjJDZAkt86XvT0Vkyy9KYMDLBXPbQF9pw2b3S eIjUe/6OIuJUM3VzjYCxKPfeguDq01dLYMwzkmyrBz8YQRYjPLIu2OTGJ3hcLt2KASy9 xDIERfDcx3PTPuAxh5LR/idQ47ASDzVurJSDz7NaE1VQ1mb4NLGHwhwklln6JFEiyqNW Q81Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cdwd52xMOEsts33nPTq3Yie0Cs+8iOghkZXQ65+/Yes=; b=fijWkVBrZnS3MAndCNg7fv7sACgevA4cIfOXI27DeNLMjBdwhWV4dMQ1C6bJx3HHpC /RI3bHL4221g5cFizMkCVoBcL1GIQW1cYnmYHnHDdCkGuzKXZ9QCJl0CrbEuiCO/uv9p AGhusxr7LdNSd8YZkf1IEIueuthb2xz96sqZlnue9CWuoMwgWv4QWa3b1SXzUbcOjI75 NAYrxRLHZrMzPBOfU9IpIststwdcy1YjYs6W9BDPC8Z4lLRxjtDBS+biaYG0cJe0aIsV S4hSIcKLSHzzD4W8Hj9Pdxg9kplX4uAn7GcHVjlkfYyOkngaQg9g63Ph1mJo+8/Y/Zcx tTMg==
X-Gm-Message-State: AE9vXwOZMGbzUlbfPvD773LYS/YhLl4T60xlaI+X+V7cPAp15qwPf4wdZv/sQGHvzf2quXsuG96c3vLterbWXw==
X-Received: by 10.202.252.206 with SMTP id a197mr4807414oii.130.1474571813607; Thu, 22 Sep 2016 12:16:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.63.153 with HTTP; Thu, 22 Sep 2016 12:16:52 -0700 (PDT)
In-Reply-To: <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in>
References: <C1E751BC-55E9-4D8C-A6A5-B5674835870E@vigilsec.com> <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thu, 22 Sep 2016 14:16:52 -0500
Message-ID: <CAHBDyN5g7PR9NE7tYNDjxL_cmDPdwB0zqUq9Cbj2f0Qawh1NQA@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Content-Type: multipart/alternative; boundary="001a113df21c255fe5053d1d819d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/Cdkaa8kQEtlXoJTD5MlBFAev9D8>
Cc: IETF STIR Mail List <stir@ietf.org>, Russ Housley <housley@vigilsec.com>
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, 22 Sep 2016 19:16:58 -0000

On Tue, Sep 20, 2016 at 8:41 PM, Alissa Cooper <alissa@cooperw.in> wrote:

> I did my AD review of this document early to try to expedite the process.
>
> = General =
>
> Should this document obsolete RFC 4474? Apologies if this was discussed
> and I'm failing to recall it. My answer would be yes I think, since new
> implementations of RFC 4474 are discouraged and this document is
> deprecating its syntax and its registries.
>
[MB] I made this comment a couple versions back and it hadn't yet been
incorporated.  I personally think it should be obsoletes as opposed to
updates.  [/MB]

>
> = Section 4.1 =
>
> (1)
> "Third, the JSON key "iat" MUST appear, set to the value of a
>       quoted encoding of the value of the SIP Date header field as a
>       JSON NumericDate (as UNIX time, per [RFC7519] Section 2)."
>
> I think this needs one more sentence to explain that while RFC 7519
> specifies that "iat" reflect the time the JWT was issued, there may be
> cases where an authorization service mints a JWT on behalf of an endpoint
> at some point later than what the SIP Date reflects. Given that the JWT is
> being created on behalf of the user (and how and why "iat" is used by
> 4474bis implementations), using the SIP Date rather than the time at which
> the JWT is actually created is acceptable.
>
> (2)
> "Defining how a SIP implementation
>    would provision multiple originating or destination identities is
>    left as a subject for future specification."
>
> I'm assuming this meant to say that defining how a STIR implementation
> deals with multiple identities is what is left for future specification. Is
> that correct? If so, it would be helpful to clarify.
>
> (3)
> "Also note that in some cases, the
>    "orig" and "dest" arrays might be populated with more than one value."
>
> The passport spec says that "orig" MUST only have one value. Should this
> text align with that? Or is this meant to allow for future extensibility of
> passport?
>
> = Section 8.3 =
>
> (1)
> "This will be the case, for
>       example, for nationally-specific service numbers (e.g. 911, 112);
>       however, the routing procedures associated with those numbers will
>       likely make sure that the verification service understands the
>       context of their use."
>
> I don't understand what is meant by the text after the semi-colon. Is the
> point that the lack of canonicalization is ok because a verifier that is
> asked to verify 112 will be designed to know that 112 is special?
>
> (2)
> "If not, implementations SHOULD convert the number into E.164 format,
>       adding a country code if necessary; this may involve transforming
>       the number from a dial string (see [RFC3966]), removing any
>       national or international dialing prefixes or performing similar
>       procedures.  ...
>       Other transformations during canonicalization MAY be made in
>       accordance with specific policies used within a local domain."
>
> Aren't all of the "other transformations" subsumed under the umbrella of
> converting to E.164 format? I find it confusing to see these discussed as
> two separate requirements. I think it's fine to point out that some domains
> will need to take their own unique steps to eventually get their numbers
> into E.164 format, but that doesn't imply that there is one set of
> transformations that SHOULD happen and another set of transformations that
> MAY happen, right?
>
> = Section 13.3 =
>
> Shouldn't the existing alg parameter have its reference updated to point
> to this document?
>
>
> Nits:
>
> = Section 1 =
>
> A forward reference to Section 10 should be added to the last paragraph.
>
> = Section 2 =
>
> s/from an "identity field" a SIP request/from an "identity field" in a SIP
> request/
>
> = Section 4.1 =
>
> "the following elements message MUST be placed" -- I'm assuming "message"
> is extraneous and should be deleted?
>
> s/key "typ" key/key "typ"/
>
> s/from addr-spec of the From header/from the addr-spec component of the
> From header/
>
> OLD
> This specification inherits
>    from the PASSporT specification one value for the 'alg' parameter:
>    'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
>    digital signature.  All implementations of this specification MUST
>    support the required signing algorithms of PASSporT.
>
> NEW
> All implementations of this specification MUST support the required
> signing algorithms of PASSporT. At present there is one
> mandatory-to-support value for the 'alg' parameter:
>    'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
>    digital signature.
>
> = Section 6.2.1 =
>
> I think it would help to provide a little bit of rationale for this
> recommendation: "As a guideline, this specification recommends that only if
> a
>    verifier determines all Identity header fields within a message are
>    invalid should the request be considered to have an invalid identity."
>
> = Section 6.2.2 =
>
> s/reason phase/reason phrase/
>
> = Section 10 =
>
> OLD
> it would likely fail the request due to the absence of an
>    Identity-Info header field with a 436 response code.
>
> NEW
> it would likely fail the request with a 436 response code due to the
> absence of an
>    Identity-Info header field.
>
> = Section 13.4 =
>
> I think this section should clearly instruct IANA to delete the registry.
>
>
> Alissa
>
>
> > On Sep 10, 2016, at 12:01 PM, Russ Housley <housley@vigilsec.com> wrote:
> >
> >
> > A revised document to address the issues raised in the first WG Last Call
> > on this document was posted yesterday.
> > (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-12.txt).
> >
> > This message starts a second two-week WG Last Call for this document,
> > which will end on 24 September 2016.
> >
> > Please review the document and send comments on it to the STIR WG mail
> > list.  Please clearly state your opinion as to whether the document is
> > ready for publication as a standards-track RFC.  Remember that support
> > for publication is needed, so if you think the document is ready to go
> > forward, please say so.
> >
> > Thanks,
> > Russ & Robert
> >
> >
> > _______________________________________________
> > stir mailing list
> > stir@ietf.org
> > https://www.ietf.org/mailman/listinfo/stir
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>