Re: [stir] Second WG Last Call for RFC4474bis

"Peterson, Jon" <> Thu, 22 September 2016 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03F8F12BD08 for <>; Thu, 22 Sep 2016 12:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.701
X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c7iNYXOKospq for <>; Thu, 22 Sep 2016 12:12:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C09FC12BCE4 for <>; Thu, 22 Sep 2016 12:12:53 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u8MJ46sQ014444; Thu, 22 Sep 2016 15:12:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version;; bh=B+3tWgB4+adqZYwC1VessMpMIY0ZVMRxLp4CfQAEVnw=; b=IQSIpPWQt2HPZH4nx1TnJBivT5tEAA6fyPm3L5KB4u179xK48PMaIiNU0b1QzyPCloKG /grHtW1+SBpY51v8s0p16D048orKfNuCGkbYTOxn0HveKiDi4vQZ1bUH+DauJEknNZ8Z 3DQ99i/UrLw97t6TdN/SxgsG6o+LAxGDCcNNOU9DyZf9U3zvzf7mf/A3vPjZnpCZ+3bi Ofk751gvAkvIaAFmSm+hP0G6gkB3g2nwZgvwwwmEhMe9gnTA/wwrQ6DfJez41ZsL0qpi OtmxaHtnIPG0gFjudfYqNOc6cIrPBGSTTCEl65Go/EHMy+aEH/qIDAdy+8KTY1Oy382C dw==
Received: from ([]) by with ESMTP id 25kabms7x9-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Sep 2016 15:12:50 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Thu, 22 Sep 2016 15:12:49 -0400
From: "Peterson, Jon" <>
To: Alissa Cooper <>, Russ Housley <>
Thread-Topic: [stir] Second WG Last Call for RFC4474bis
Thread-Index: AQHSC3yUpcAXn9+uD0OZaEWmNt6JrqCDfpmAgAJCuwA=
Date: Thu, 22 Sep 2016 19:12:49 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609220333
Archived-At: <>
Cc: IETF STIR Mail List <>
Subject: Re: [stir] Second WG Last Call for RFC4474bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Sep 2016 19:12:56 -0000

Thanks, we can get these cleaned up. A few notes below.

Jon Peterson
Neustar, Inc.

On 9/20/16, 6:41 PM, "stir on behalf of Alissa Cooper"
< on behalf of> wrote:

>"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.

Okay, we can explain a bit - I think probably what the text needs to say
is that the auth service should when adding "iat" inspect the Date and
make sure it is within the freshness window before signing. Also, if for
whatever reason the auth service wants to sign what it sees as the Date,
rather than what the SIP header says is the Date, it is allowed to do so
provided that it includes "canon". The text that supports this behavior is
given in the verification service behavior (and in 12.1) but not really

>"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.

Well, this means more aligning STIR with potential ways that SIP might
signify that a request is "To" multiple destinations or "From" multiple
parties, say. Even when PAI is present and is different from the From,
there is still a general sense in personal communications that they are
from some person (a persona even). We do have some vague notion that we
want to work with meshed and centralized conferences, though, and don't
want to close the door on that, which is why there's some forward-looking
text about this here, and why the text is pretty broad.

>"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?

This shows that we're not being entirely consistent in our
future-proofing. I'd be willing to narrow this down to only one "orig"
identity being allowed (and thus bring rfc4474bis into parity with
PASSporT on this). Like I said, generally speaking personal communication
are from like one person.

>= Section 8.3 =
>"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?

It means that routing procedures for service numbers are very unusual, and
that the meaning of a service number is much more specific to its context
than is an E.164 number. The process of successfully routing to 911
necessarily involves the hops (and any STIR intermediaries) being in a
context where 911 will be understood. I can try to find a more helpful
wording for that.

>"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?

No, I think you're right. It is all effectively one set of transformations
that we are RECOMMENDing: we can anticipate what some members of the set
are, but not others. I'll reword accordingly.

>= Section 13.3 =
>Shouldn't the existing alg parameter have its reference updated to point
>to this document?

Sure, good point.

Will fix the nits. Just one to comment on:

>= 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."

The idea here is that if you don't support a "ppt" or lack some private
credential required to access one Identity header, that doesn't mean you
still can't find another Identity header that you can understand and
validate in the request, and that if you find at least one that looks
valid, you can accept the identity it covers. Maybe it would help to
rephrase this affirmatively that way, rather than describing the rainy day