Subject: [stir] Review of: draft-ietf-stir-rfc4474bis-10

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Aug 2016 20:46:07 -0700

Review of:  Authenticated Identity Management in the Session Initiation
             Protocol (SIP)
ID:         draft-ietf-stir-rfc4474bis-10.txt
Date:       8 August 2016
Reviewer:   D. Crocker <[email-masked]>

Summary
-------

SIP needs to support a mechanism that validates the identifier used for 
the originator of the request. That is, to ensure that the entity that 
placed the identification value into the field was authorized by its 
owner to do so.  This specifications is part of a collection of 
specifications intended to enable such validation.

Taken on its own and also when taken with its companion documents, the 
specifications are confusing and incomplete.  It is quite far from being 
ready for publication.

Terminology is used inconsistently. It often is introduced with no 
background or citation.  Many uses of 'header' are probably supposed to 
be 'header field'.  My sense is that quite a bit of terminology is used 
equally loosely.

There is no integrative architectural description, so the reader has 
difficulty understanding what all of the pieces are or how they fit 
together.  In fact is appears that the document itself gets confused on 
this matter.

Algorithms are all offered only as prose and often in a form mitigating 
comprehension, such as tending towards negation or disjunction, which 
humans process less well than affirmatives and conjunctions. From what I 
can tell, the algorithms often are incomplete, but serious analysis is 
difficult.

The documents appear to rely on a reader's having quite a bit of prior 
knowledge and are certainly not usable by an implementer who is not 
already deeply embedded in the community that produced these 
specifications.  My impression is that being embedded won't suffice 
either, both from my assessment of the documents' deficiencies and given 
back-channel comments I have heard about the expectation of the work to 
be done after these specifications are published.

Overall, the writing impedes comprehension and the document needs a very 
diligent pass by a technical editor.  I suspect this will uncover quite 
a number of semantic deficiencies in the text.

There is a possible tendency to support more alternative behavior than 
appropriate. Successful interoperability usually benefits from fewer 
choices, not more.  Common, mandatory canonicalization is an example.

Credentials: the specification neither defines nor references a standard 
for the specification of credentials, here.  That means that the 
technical details -- as distinct from the operational policies -- of 
credentials are out of scope, although they are fundamental to proper 
operation of this serve.  This is a showstopper, in terms of 
specification completeness for the service.

How is the recipient to know what credential 'standard' is used?  How 
does this ensure interoperability between two participants who have not 
interacted before?

At base, these specifications appear intended to roughly chart out a 
system structure, leaving most of the difficult work for later and 
elsewhere.  By way of example, there are few if any cross-organization 
key management services on the Internet that demonstrate the utility 
needed here.  I am pretty sure that Web certs don't qualify.  We know 
that DKIM's operation does, of course.  However DKIM strictly uses 
domain names as identifiers and they conveniently align with their 
administrative authorities, whereas telephone numbers do not...

      [[[ The mailing list just had an extensive regurgitation of 
critical commentary about ENUM.  What appears to be getting missed is 
that whatever mechanism is going to be used for finding and validating 
keys is going to have no operational history of reliability, safety or 
efficacy. ]]]

There is remarkably little of the original RFC 4474 substance still in 
this document.  Calling it a bis is a bit like tearing all of a building 
except its fireplace or its front door and calling that a remodeling. 
The previous document does not have an installed base, so I strongly 
suggest removing all references to it.  It will allow some of the text 
to be notably simpler and clearer.

The document is heavy with forward references.  These force the reader 
to stop what they are in the middle of, try to hold that place, and look 
forward to understand what they've just been interrupted from reading. 
As a literary style, forward references create useful tension.  In 
specifications they just interrupt the flow.  The document should be 
reorganization so that integrative text comes /after/ the text 
describing the pieces being integrated.  And opening overview, design 
summary, or the like can give a non-normative description of the 
architecture and the service, so the reader has a basic sense of the big 
picture, before diving into the detail of those to-be-integrated pieces.

Detail Comments
---------------

> Abstract
>
>    The baseline security mechanisms in the Session Initiation Protocol
>    (SIP) are inadequate for cryptographically assuring the identity of
>    the end users that originate SIP requests, especially in an

          an end user originating a SIP request

           cryptographically -> adequately

'cryptographically' is not the issue here  That is, it is a means, not 
an end.

>    interdomain context.  This document defines a mechanism for securely

'interdomain' might suffice, but I suspect it's worth pressing the 
issue, with language like "especially across trust boundaries" or somesuch.

>    identifying originators of SIP requests.  It does so by defining a
>    SIP header field for conveying a signature used for validating the
>    identity, and for conveying a reference to the credentials of the
>    signer.
...

> 1.  Introduction
>
>    This document provides enhancements to the existing mechanisms for
>    authenticated identity management in the Session Initiation Protocol
>    (SIP, [RFC3261]).  An identity, for the purposes of this document, is
>    defined as either a SIP URI, commonly a canonical address-of-record
>    (AoR) employed to reach a user (such as
>    'sip:[email-masked]'), or a telephone number, which can be
>    represented as either a TEL URI [RFC3966] or as the user portion of a
>    SIP URI.

I suspect it does not 'enhance' existing mechanisms as much as add a new 
one.  If the claim is actual enhancement, then what mechanism is 
enhanced and how does authenticating origin constitute enhancement of 
it?  My point is that I believe the existing mechanisms will operate the 
same in the future as they have been.  This spec doesn't change them.

Move definitions to an explicit terminology section, rather than putting 
them into an Introduction.  Also, does this document use the term 
differently than elsewhere than SIP???  Then why is 'for the purposes of 
this document' included?

>    [RFC3261] specifies several places within a SIP request where users
>    can express an identity for themselves, most prominently the user-
>    populated From header field.  However, the recipient of a SIP request
>    has no way to verify that the From header field has been populated
>    appropriately, in the absence of some sort of cryptographic
>    authentication mechanism.  This leaves SIP vulnerable to a category
>    of abuses, including impersonation attacks that enable robocalling
>    and related problems as described in [RFC7340].  Ideally, a
>    cryptographic approach to identity can provide a much stronger and
>    less spoofable assurance of identity than the Caller ID services that
>    the telephone network provides today.
>
>    [RFC3261] encourages user agents (UAs) to implement a number of
>    potential authentication mechanisms, including Digest authentication,
>    Transport Layer Security (TLS), and S/MIME (implementations may
>    support other security schemes as well).  However, few SIP user
>    agents today support the end-user certificates necessary to
>    authenticate themselves (via S/MIME, for example), and for its part
>    Digest authentication is limited by the fact that the originator and
>    destination must share a prearranged secret.  Practically speaking,
>    originating user agents need to be able to securely communicate their
>    users' identity to destinations with which they have no previous
>    association.
>
>    As an initial attempt to address this gap, [RFC4474] specified a
>    means of signing portions of SIP requests in order to provide an
>    identity assurance.  However, RFC 4474 was in several ways misaligned
>    with deployment realities (see [I-D.rosenberg-sip-rfc4474-concerns]).
>    Most significantly, RFC 4474 did not deal well with telephone numbers
>    as identifiers, despite their enduring use in SIP deployments.  RFC
>    4474 also provided a signature over material that intermediaries in
>    existing deployments commonly altered.  This specification therefore
>
>
>
> Peterson, et al.         Expires January 8, 2017                [Page 3]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    revises RFC 4474 in light of recent reconsideration of the problem
>    space to align with the threat model in [RFC7375], and aligns the
>    signature format with PASSporT [I-D.ietf-stir-passport].

This kind of review of history is best relegated to a minor location in 
the document.  If the current spec is successful, history like this will 
be distracting, 10 years from now....

> 2.  Terminology
>
>    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
>    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
>    RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
>    described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919].
>
> 3.  Background

This section includes far more than background.  It also provides a 
summary description of the mechanism being defined here.  I suggest 
having this section only give background on sip and the problem, with a 
separate section for the design summary.  Or else call this 
Introduction, but really it would be better to split them.

>    Per [RFC7340], problems such as robocalling, voicemail hacking, and
>    swatting are enabled by an attacker's ability to impersonate someone
>    else.  The secure operation of most SIP applications and services
>    depends on authorizing the source of communications as it is
>    represented in a SIP request.  Such authorization policies can be
>    automated or be a part of human operation of SIP devices.  An example
>    of the former would be a voicemail service that compares the identity
>    of the caller to a whitelist before determining whether it should
>    allow the caller access to recorded messages.  An example of the
>    latter would be an Internet telephone application that displays the
>    calling party number (and/or Caller-ID) of a caller, which a human
>    may review to make a policy decision before answering a call.  In
>    both of these cases, attackers might attempt to circumvent these
>    authorization policies through impersonation.  Since the primary
>    identifier of the sender of a SIP request, the From header field, can
>    be populated arbitrarily by the controller of a user agent,
>    impersonation is very simple today in many environments.  The

add:  Hence the foundation to accurate authorization is valid 
authentication.

>    mechanism described in this document provides a strong identity
>    system for detecting attempted impersonation in SIP requests.

           "provides a strong identity system for detecting" could mean 
many things, whereas the goal here is quite specific.

So replace it with:

           ...enables an authentication capability for protecting against...

>    This identity architecture for SIP depends on a logical
>    "authentication service" which validates outgoing requests.  An

It likely will validate them in multiple places, including incoming 
requests.

>    authentication service may be implemented either as part of a user
>    agent or as a proxy server; typically, it is a component of a network
>    intermediary like a proxy to which originating user agents send
>    unsigned requests.  Once the sender of the message has been
>    authenticated, the authentication service then computes and adds

sender?  Does that mean the caller?  the caller's ua?  the caller's 
operator?  the term is ambiguous.

>    cryptographic information (including a digital signature over some
>    components of messages) to requests to communicate to other SIP
>    entities that the sending user has been authenticated and its claim

worth breaking this sentence into two, for better clarity.

>    of a particular identity has been authorized.  A "verification
>    service" on the receiving end then validates this signature and
>    enables policy decisions to be made based on the results of the
>    verification.
>
>
>
>
> Peterson, et al.         Expires January 8, 2017                [Page 4]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    Identities are issued to users by authorities.  When a new user
>    becomes associated with example.com, the administrator of the SIP
>    service for that domain can issue them an identity in that namespace,
>    such as [email-masked].  Alice may then send REGISTER requests to
>    example.com that make her user agents eligible to receive requests
>    for sip:[email-masked].  In some cases, Alice may be the owner of
>    the domain herself, and may issue herself identities as she chooses.
>    But ultimately, it is the controller of the SIP service at
>    example.com that must be responsible for authorizing the use of names
>    in the example.com domain.  Therefore, for the purposes of baseline
>    SIP, the credentials needed to prove a user is authorized to use a
>    particular From header field must ultimately derive from the domain
>    owner: either a user agent gives requests to the domain name owner in
>    order for them to be signed by the domain owner's credentials, or the
>    user agent must possess credentials that prove in some fashion that
>    the domain owner has given the user agent the right to a name.
>
>    The situation is however more complicated for telephone numbers,
>    however.  Authority over telephone numbers does not correspond

          however...however

>    directly to Internet domains.  While a user could register at a SIP
>    domain with a username that corresponds to a telephone number, any
>    connection between the administrator of that domain and the
>    assignment of telephone numbers is not currently reflected on the
>    Internet.  Telephone numbers do not share the domain-scope property
>    described above, as they are dialed without any domain component.
>    This document thus assumes the existence of a separate means of
>    establishing authority over telephone numbers, for cases where the
>    telephone number is the identity of the user.  As with SIP URIs, the
>    necessary credentials to prove authority for a name might reside
>    either in the endpoint or at some intermediary.

Note that the preceding discussion makes no mention of "SIP URI".  If 
one reads back and connects some dots, the reader might guess that the 
alice@ discussion is for a SIP URI, but the text should make this explicit.

The following paragraph really is the design summary for the specification:

>    This document specifies a means of sharing a cryptographic assurance
>    of end-user SIP identity in an interdomain or intradomain context.

I suspect the above sentence is seriously redundant.  If it isn't, it 
needs to be quite a bit sooner, since it is fundamental.  Certainly it 
is not 'background'.

>    It relies on the authentication service constructing tokens based on
>    the PASSporT [I-D.ietf-stir-passport] format, a JSON [RFC7159] object
>    comprising values copied from certain header field values in the SIP
>    request.  The authentication service then computes a signature over
>    those JSON object in a manner following PASSporT.  That signature is

"those JSON object" ?

Also, where is the object?  How is it created? How is it conveyed?

Also 'The authentication service' might refer to the signing side or to 
the verifying side.  How is the reader to know for certain?  A diagram 
of the overall service and its components could be quite helpful.

>    then placed in a SIP Identity header.  In order to assist in the

         header /field/?

>    validation of the Identity header, this specification also describes
>    some metadata fields associated with the header that can be used by
>    the recipient of a request to recover the credentials of the signer.
>    Note that the scope of this document is limited to providing this
>    identity assurance for SIP requests; solving this problem for SIP
>    responses is outside the scope of this work (see [RFC4916]).  Future
>    work might specify ways that a SIP implementation could gateway
>    PASSporT objects to other protocols.

And it might not.  To the extent that you have to say something about 
work that might or might not be done, just cite the topic and that it 
isn't covered here.  Such as:

           Gatewaying Passport objects to other services is outside the 
scope of this specification.

(Odd thought:  Given that JSON isn't native to SIP and that there must 
be some translation/encoding of the json object to work with SIP, that 
effectively means that this /is/ a gatewaying application of the object...)

>
>
> Peterson, et al.         Expires January 8, 2017                [Page 5]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    This specification allows either a user agent or a proxy server to
>    provide the authentication service function and/or the verification
>    service function.  To maximize end-to-end security, it is obviously
>    preferable for end-users to acquire their own credentials; if they

"To maximize end-to-end security, it is obviously preferable for 
end-users to acquire their own credentials;?

I'm not exactly sure what this means or is supposed to mean, but I 
suspect it's incorrect.

>    do, their user agents can act as authentication services.  However,
>    for some deployments, end-user credentials may be neither practical
>    nor affordable, given the potentially large number of SIP user agents
>    (phones, PCs, laptops, PDAs, gaming devices) that may be employed by
>    a single user.  In such environments, synchronizing keying material
>    across multiple devices may be prohibitively complex and require
>    quite a good deal of additional endpoint behavior.  Managing several
>    credentials for the various devices could also be burdensome.  In
>    these cases, implementation the authentication service at an
>    intermediary may be more practical.  This trade-off needs to be
>    understood by implementers of this specification.
>
> 4.  Overview of Operations
>
>    This section provides an informative (non-normative) high-level
>    overview of the mechanisms described in this document.

           described -> specified (or defined)

But note that we've already been given a high-level overview...

On reflection, this section isn't an 'overview'.  It's an example 
scenario.  The essential difference is that this makes specific choices, 
such as use of a proxy, which might not apply in some valid scenarios. 
As some integrative pedagogy, that's fine.  So I suggest re=labeling the 
section rather than changing it's substance.

>    Imagine a case where Alice, who has the home proxy of example.com and
>    the address-of-record sip:[email-masked], wants to communicate
>    with Bob at sip:[email-masked].  They have no prior relationship,
>    and Bob implements best practices to prevent impersonation attacks.
>
>    Alice generates an INVITE and places her identity, in this case her
>    address-of-record, in the From header field of the request.  She then
>    sends an INVITE over TLS to an authentication service proxy for the
>    example.com domain.

How is reference to TLS meaningful here?

>
>    The proxy authenticates Alice (possibly by sending a Digest
>    authentication challenge), and validates that she is authorized to

Again, how is discussion of the internal, non-STIR aspects of SIP 
operationally relevant here?

>    assert the identity that she populated in the From header field.
>    This value could be Alice's AoR, but in other cases it could be some
>    different value that the authentication service has authority over,

That bit of vagueness isn't helpful, given the motivation for doing this 
work.  It reduces to:  something will get authenticated, but we won't 
say what and we won't say where to find out.

>    such as a telephone number.  The proxy authentication service then
>    constructs a PASSporT object which contains a JSON representations of
>    headers and claims which mirror certain parts of the SIP request,
>    including the identity in the From header field.  As a part of
>    generating the PASSporT object, the authentication service signs a
>    hash of those headers and claims with the appropriate credential for
>    the identity (in this case, the certificate for example.com, which
>    covers the identity sip:[email-masked]), and the signature is
>    inserted by the proxy server into the Identity header field value of
>    the request.  Optionally, the JSON headers and claims themselves may
>    also be included in the object, encoded in the "canon" parameter of
>    the Identity header.

why? when?

Tossing in vague references about optional behavior that is neither 
motivated nor explained usually proves more of a distraction than a 
help, when writing an 'overview' or an example.

>
>
>
> Peterson, et al.         Expires January 8, 2017                [Page 6]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    The proxy, as the holder of the private key for the example.com
>    domain, is asserting that the originator of this request has been
>    authenticated and that she is authorized to claim the identity that
>    appears in the From header field.  The proxy inserts an "info"
>    parameter into the Identity header that tells Bob how to acquire
>    keying material necessary to validate its credentials (a public key),
>    in case he doesn't already have it.

A scheme that has an untrusted object carrying information about where 
to find trust information for the object sounds like a serious security 
hole.  Why should the pointer be trusted?

>    When Bob's domain receives the request, it verifies the signature
>    provided in the Identity header, and thus can validate that the
>    authority over the identity in the From header field authenticated
>    the user, and permitted the user to assert that From header field
>    value.  This same validation operation may be performed by Bob's user
>    agent server (UAS).  As the request has been validated, it is
>    rendered to Bob. If the validation was unsuccessful, some other
>    treatment would be applied by the receiving domain.

Huge operational transition question:  How is the absence of the 
signature treated?  Today, there are no signatures.  Tomorrow there 
might be some, both it won't be true that /all/ incoming requests are 
signed.  So how is the receiver supposed to handle the absence of a 
signature?

Related question:  Is everyone certain that transit of the request will 
/never/ break the signature?  What is the basis for that assessment? And 
if a signature /can/ break, then the interpretation of an invalid 
signature could mean either spoofing or operational error.

>
> 5.  Signature Generation and Validation
>
> 5.1.  Authentication Service Behavior
>
>    This document specifies a role for SIP entities called an

        delete first sentence.  it adds no useful information.

>    authentication service.  The authentication service role can be
>    instantiated, for example, by an intermediary such as a proxy server

Constant references to implementation (and 'instantiation') 
possibilities distracts from the required task of defining the 
architecture and functions of the service.

>    or by a user agent.  Any entity that instantiates the authentication
>    service role MUST possess the private key of one or more credentials

        "private key of one or more credentials" - not sure what this means?

One key can have more than one credential?  On the signing side, I'd 
expect the process to start by choosing a credential and then using its 
associated key.

Simpler wording:   The authentication service possesses the private...

>    that can be used to sign for a domain or a telephone number (see

         can be used to sign the From identity.

>    Section 6.1).  Intermediaries that instantiate this role MUST be

forward reference.  better to put that material before this.

>    capable of authenticating one or more SIP users who can register for

          one or more SIP users -> users

the word identity hasn't bee used in this paragraph, before this, so the 
referent is unclear.

Also, this requirement for authentication appears to be redundant with 
the later specification for authentication in Step 2.

>    that identity.  Commonly, this role will be instantiated by a proxy
>    server, since these entities are more likely to have a static
>    hostname, hold corresponding credentials, and have access to SIP
>    registrar capabilities that allow them to authenticate users.  It is
>    also possible that the authentication service role might be
>    instantiated by an entity that acts as a redirect server, but that is
>    left as a topic for future work.

Not only is the above, last sentence about future work; it appears to be 
entirely irrelevant to this specification.  Remove it.

>
>    An authentication service adds the Identity header to SIP requests.

Note that we've read this before.  So I'm raising a redundancy flag.

>    The procedures below define the steps that must be taken when each an
>    header is added.  More than one may appear in a single request, and

          header -> header /field/ ?

And, by the way, what header field is that?

The "the procedures" sentence adds nothing and is redundant with the 
later "entities instantiating" sentence.

In any event, don't make forward references like this.  Put it after the 
relevant details, so that there already is context and this just 
enhances it.

      From what I can tell, this entire paragraph should be moved toward 
the end of this section.

>    an authentication service may add an Identity header to a request
>    that already contains one or more Identity headers.  If the Identity
>    header added follows extended signing procedures beyond the baseline
>    given in Section 8, then it differentiates the header with a "ppt"
>    parameter per the fourth step below.
>
>
>
>
>
>
> Peterson, et al.         Expires January 8, 2017                [Page 7]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    Entities instantiating the authentication service role perform the
>    following steps, in order, to generate an Identity header for a SIP
>    request:

          The authentication service performs the following steps in 
order, to...

Procedural detail should be in a procedural form.  Extended prose like 
this isn't as easily grokked.  That invites both writing and reading 
errors to the algorithm.

>    Step 1:

          Step 1:  Authoritative for Identity

>    First, the authentication service must determine whether it is
>    authoritative for the identity of the sender of the request.  In
>    ordinary operations, the authentication service decides this by
>    inspecting the URI value from the addr-spec component of From header
>    field; this URI will be referred to here as the 'identity field'.  If
>    the identity field contains a SIP or SIP Secure (SIPS) URI, and the
>    user portion is not a telephone number, the authentication service

how is its not being a telephone number determined deterministically and 
correctly?

>    MUST extract the hostname portion of the identity field and compare
>    it to the domain(s) for which it is responsible (following the
>    procedures in RFC 3261 [RFC3261], Section 16.4).  If the identity
>    field uses the TEL URI scheme [RFC3966], or the identity field is a
>    SIP or SIPS URI with a telephone number in the user portion, the
>    authentication service determines whether or not it is responsible
>    for this telephone number; see Section 7.1 for more information.  An

This canonicalization text seems entirely out of place, in the middle of 
specification about authority.

>    authentication service proceeding with a signature over a telephone
>    number MUST then follow the canonicalization procedures described in
>    Section 7.2.  If the authentication service is not authoritative for
>    the identity in question, it SHOULD process and forward the request
>    normally unless the local policy is to block such requests.  The
>    authentication service MUST NOT add an Identity header if the
>    authentication service does not have the authority to make the claim
>    it asserts.
>
>    Step 2:

       Step 2:  Authorization

>
>    The authentication service MUST then determine whether or not the

[or not] remove

>    sender of the request is authorized to claim the identity given in

        sender:  calling user?, calling ua?, originating operator? 
intermediary?  Although the word is used frequently in the SIP spec, it 
is not defined.

>    the identity field.  In order to do so, the authentication service
>    MUST authenticate the sender of the message.  Some possible ways in
>    which this authentication might be performed include:

Remove the pedagogy after the first sentence.  The choices are outside 
of this specification and the spec is not enhanced by pedagogy about 
technical matters outside of its scope.

Also isn't the first sentence redundant with other text in the spec?

>
>       If the authentication service is instantiated by a SIP
>       intermediary (proxy server), it may authenticate the request with
>       the authentication scheme used for registration in its domain
>       (e.g., Digest authentication).
>
>       If the authentication service is instantiated by a SIP user agent,
>       a user agent may authenticate its own user through any system-
>       specific means, perhaps simply by virtue of having physical access
>       to the user agent.
>
>
>
>
>
> Peterson, et al.         Expires January 8, 2017                [Page 8]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    Authorization of the use of a particular username or telephone number
>    in the user part of the From header field is a matter of local policy
>    for the authentication service; see Section 6.1 for more information.
>
>    Note that this check is performed only on the addr-spec in the
>    identity field (e.g., the URI of the sender, like
>    'sip:[email-masked]'); it does not convert the display-
>    name portion of the From header field (e.g., 'Alice Atlanta').  For
>    more information, see Section 12.6.

'checking' and 'converting' are very different actions.  So 'it does 
not' does not flow from the preceding text in the sentence.

>    Step 3:

         Step 3:  Timestamp

>
>    An authentication service MUST add a Date header field to SIP

Why?  (Probably only need to cite the earlier discussion about its use 
for replay mitigation. But merely cite; don't duplicate.)

>    requests that do not have one.  The authentication service MUST
>    ensure that any preexisting Date header in the request is accurate.
>    Local policy can dictate precisely how accurate the Date must be; a
>    RECOMMENDED maximum discrepancy of sixty seconds will ensure that the
>    request is unlikely to upset any verifiers.  If the Date header
>    contains a time different by more than one minute from the current
>    time noted by the authentication service, the authentication service
>    SHOULD reject the request.  This behavior is not mandatory because a
>    user agent client (UAC) could only exploit the Date header in order
>    to cause a request to fail verification; the Identity header is not
>    intended to provide a source of non-repudiation or a perfect record

Then where does the non-repudiation feature of STIR come from?

>    of when messages are processed.  Finally, the authentication service
>    MUST verify that both the Date header and the current time fall
>    within the validity period of its credential.
>
>    See Section 12 for information on how the Date header field assists
>    verifiers.
>
>    Step 4:
>
>    Subsequently, the authentication service MUST form a PASSporT object
>    and add a corresponding an Identity header to the request containing

         a corresponding an ?->? a corresponding

>    this signature.  For baseline PASSporT objects headers (without an

         baseline PASSporT objects headers
         ->
         a baseline PASSporT objects header

>    Identity header "ppt" parameter), this follows the procedures in

header?  or header field?

>    Section 8; if the authentication service is using an alternative
>    "ppt" format, it MUST add an appropriate "ppt" parameter and follow

Isn't this text repeating specification text that is elsewhere in the 
document?  If so, remove it.

>    the procedures associated with that extension (see Section 9).  After
>    the Identity header has been added to the request, the authentication
>    service MUST also add a "info" parameter to the Identity header.  The
>    "info" parameter contains a URI from which the authentication
>    service's credential can be acquired; see Section 6.3 for more on
>    credential acquisition.
>
>    Step 5:

       Step 5: Canonicalization

>
>
>
> Peterson, et al.         Expires January 8, 2017                [Page 9]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    In the circumstances described below, an authentication service will

another forward reference, this time without even a specific pointer.

>    add a "canon" parameter to the Identity header.  The syntax of
>    "canon" is given in Section 8; essentially, it contains a base64
>    encoding of the JSON header and claims in the PASSporT object.  The
>    presence of "canon" is OPTIONAL baseline PASSporT objects in SIP as a
>    because the information carried in the baseline PASSporT object's
>    headers and claims is usually redundant with information already
>    carried elsewhere in the SIP request.  Omitting "canon" can
>    significantly reduce SIP message size, especially when the PASSporT
>    object contains media keys.
>
>    When however an authentication service creates a PASSporT that uses

"When however"?

>    extension claims beyond the baseline PASSporT object, including
>    "canon" is REQUIRED in order for the verification service to be
>    capable of validating the signature.  See Section 9.
>
>    Also, in some cases, a request signed by an authentication service

"in some cases"?  This is a specification.  Where is the clear detail?

>    will be rejected by the verification service on the receiving side,

"on the receiving side" is redundant. Remove it.  Where else is there a 
verification service?

>    and the authentication service will receive a SIP 4xx status code in
>    the backwards direction, such as a 438 indicating a verification

This is offered as descriptive text here. Where is this SIP behavior 
documented in this spec?

>    failure.  If the authentication service did not originally send the

The authentication service does sending?  I think it doesn't, and the 
definition of its roles implies that it doesn't, but rather that it is 
part of one or another module that does.

>    Identity header with the "canon" parameter, it SHOULD retry a request

and hence it doesn't do retries.  All of this needs to be recast in 
terms that match the specified architecture.

>    once after receiving a 438 response, this time including the "canon".

Why?  This is just guessing.  Protocols that do guessing don't work very 
well.

This interaction needs to be re-specified to be deterministic.

>    The information in "canon" is useful on the verification side for
>    debugging errors, and there are some known causes of verification
>    failures (such as the Date header changing in transit, see
>    Section 12.1 for more information) that can be resolved by the
>    inclusion of "canon".
>
>    Finally, the authentication service MUST forward the message
>    normally.

it doesn't do forwarding.

>
> 5.2.  Verifier Behavior
>
>    This document specifies a logical role for SIP entities called a

redundant detail.

>    verification service, or verifier.  When a verifier receives a SIP
>    message containing one or more Identity headers, it inspects the

headers?  header fields?

>    signature(s) to verify the identity of the sender of the message.
>    The results of a verification are provided as input to an
>    authorization process that is outside the scope of this document.

Step 5, below, specifies a behavior that is within scope.

>    A SIP request may contain zero, one, or more Identity headers.  A
>    verification service performs the procedures above on each Identity
>    header that appears in a request.  If the verifier does not support

What does it mean to 'not support an Identity header [field]"?

Why might there be multiple Identity header [fields]?  How might they 
differ?

>    an Identity header present in a request due to the presence of an
>    unsupported "ppt" parameter, or if no Identity header is present, and
>    the presence of an Identity header is required by local policy (for
>    example, based on a per-sending-domain policy, or a per-sending-user
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 10]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    policy), then a 428 'Use Identity Header' response MUST be sent in
>    the backwards direction.  For more on this and other failure
>    responses, see Section 13.3.
>
>    In order to verify an Identity header in a message, an entity acting
>    as a verifier MUST perform the following steps, in the order here
>    specified.  Note that when an Identity header contains the optional
>    "canon" parameter, the verifier MUST follow the additional procedures
>    in Section 5.2.1.
>
>    Step 1:

        Step 1:  PPT parameter

>    The verifier MUST inspect any optional "ppt" parameter appearing the

[optional] remove.  Especially given the MUST.  It doesn't matter 
whether the ppt was optional for the signer.

"any" can there be more than one?  If only one then perhaps:

       MUST inspect the "ppt" parameter, if present in the Identity request.

>    Identity request.  If no "ppt" parameter is present, then the
>    verifier proceeds normally below.  If a "ppt" parameter value is

'normally' implies the alternative is abnormal.  also, 'below' where?

>    present, and the verifier does not support it, it MUST ignore the
>    Identity header.  If a supported "ppt" parameter value is present,
>    the verifier follows the procedures below, including the variations
>    described in Step 5.

is the 'below' here different from the one before it?

     From the above text, it appears that ppt does not affect 
processing, as long as the ppt is "supported".  That is, an absent ppt 
and a valid ppt both produce the same sequence 'below'.

>    Step 2:

        Step 2:  Signature Scope

>    In order to determine whether the signature for the identity field
>    should be over the entire identity field URI or just a canonicalized
>    telephone number, the verification service MUST follow the
>    canonicalization process described in Section 7.2.  That section also
>    describes the procedures the verification service MUST follow to
>    determine if the signer is authoritative for a telephone number.  For

Those two functions are wildly different.  Why are they part of the same 
process?

>    domains, the verifier MUST follow the process described in
>    Section 7.3 to determine if the signer is authoritative for the
>    identity field.
>
>    Step 3:

       Step 3:  Obtain Key

>    The verifier must first ensure that it possesses the proper keying
>    material to validate the signature in the Identity header field,
>    which usually involves dereferencing a URI in the "info" parameter of
>    the Identity header.  See Section 6.2 for more information on these
>    procedures.  If the verifier does not support the credential
>    described in the "info" parameter, then it should consider the

Only should?  Why???

>    credential for this header unsupported.  If a SIP request contains no
>    Identity headers with a supported credential, then the verifier MUST
>    return a 437 "Unsupported Credential" response

Verifier returns responses?

>    Step 4:

        Step 4:  Date Window Enforcement

>    The verifier MUST furthermore ensure that the value of the Date
>    header of the request meets local policy for freshness (usually,
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 11]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    within sixty seconds) and that it falls within the validity period of
>    the credential used to sign the Identity header.  For more on the
>    attacks this prevents, see Section 12.1.  If the "canon" parameter is

There was earlier discussion of using a date window validation to 
mitigate against some attacks.  There doesn't need to be yet-another 
reference here.  Just cite the earlier discussion.

>    present, the verifier should follow the Date-related behavior in
>    Section 5.2.1.
>
>    Step 5:

        Step 5: Signature Validation

>    The verifier MUST validate the signature in the Identity header field
>    over the PASSporT object.  For baseline PASSporT objects (with no
>    Identity header "ppt" parameter) the verifier MUST follow the
>    procedures for generating the signature over a PASSporT object
>    described in Section 8.  If a "ppt" parameter is present (and per
>    Step 1, is understood), the verifier follows the procedures for that
>    "ppt" (see Section 9).  If a verifier determines that the that the
>    signature in the Identity does not correspond to the reconstructed
>    signed-identity-digest, then the Identity header should be considered
>    invalid.

I suggest breaking this step into two parts:  signature regeneration and 
signature validation.

It appears that the specification is calling for two (or more???) 
different methods of doing signature validation, depending upon whether 
ppt is present.  This seems like an outstandingly bad idea.  It creates 
complexity and possibly even outright confusion.

There needs to be a single algorithm for validation, even if components 
of the algorithm have branches, such as depending on whether the 
'address' is a URI or a telephone number.

>
>    The presence of multiple Identity headers within a message raises the
>    prospect that a verification services could receive a message
>    containing some valid and some invalid Identity headers.  If the
>    verifier determines all Identity headers within a message are
>    invalid, then a 438 'Invalid Identity Header' response MUST be
>    returned.

So it's ok to have no Identity header fields but it's not ok to have 
identity, where none validate.  This means that the entire transfer 
environment is expected and required to convey Identity fields 
perfectly, all the time.

>    The verification of an Identity header does not entail any particular
>    treatment of the request.  The handling of the message after the
>    verification process depends on how the implementation service is
>    implemented and on local policy.  This specification does not propose
>    any authorization policy for user agents or proxy servers to follow
>    based on the presence of a valid Identity header, the presence of an
>    invalid Identity header, or the absence of an Identity header, but it
>    is anticipated that local policies could involve making different
>    forwarding decisions in intermediary implementations, or changing how
>    the user is alerted, or how identity is rendered, in user agent
>    implementations.

I suspect the above paragraph belongs elsewhere and sooner.  It isn't 
part of the step sequence.

>
> 5.2.1.  Handling 'canon' parameters
>
>    If the optional "canon" parameter of the Identity header is present,

[optional]  remove. it's redudnant with 'if'

[of the Identity header] remove.  there is no other canon parameter.

But really I suspect that even the 'if' is unecessary.  The optionality 
has been established elsewhere.  The task here is merely to specify what 
is in a canon.

>    it contains a base64 encoding of the header and claim component of

This appears to be a re-specification of canon.  Don't do that.  Cite 
its spec and then simply use it.

>    the PASSporT object constructed by the authentication service, and
>    this it conveys any canonical telephone number formats created by the

      this -> thus ?

there are multiple canon formats?  that doesn't sound very canonical.

but again, stating what it conveys is redundant.

>    authentication service (see Section 7.2), as well as an "iat" claim
>    corresponding to the Date header that the authentication service
>    used.  The "canon" is provided purely as an optimization and
>    debugging mechanism for the verification service.

This is the wrong place to state what canon is for.

>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 12]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    When "canon" is present, the verification service MAY compute its own

'MAY'???  I don't understand making canonicalization optional, either 
during signing or during verification.

>    canonicalization of the numbers and compare them to the values in the
>    "canon" parameter before performing any cryptographic functions in
>    order to ascertain whether or not the two ends agree on the canonical
>    number form.  Also, when "canon" is present, during Step 4 the
>    verification service SHOULD compare the "iat" value in the "canon" to

This is talking about actions during Step 4.  Move it to Step 4!

>    its Date header field value.  If the two are different, and the "iat"
>    value is later but within verification service policy for freshness,
>    the verification service SHOULD perform the computation required by
>    Step 5 using the "iat" value instead of the Date value.  As some
>    deployments in the field have been observed to change the Date header
>    in transit, this procedure will prevent some unnecessary verification
>    failures.

[unnecessary] remove.

But it won't prevent others.  This means that signatures that were valid 
will break.  And this ought to mitigate the handling of broken signatures.

>
> 6.  Credentials
>
> 6.1.  Credential Use by the Authentication Service
>
>    In order to act as an authentication service, a SIP entity must have
>    access to the private keying material of one or more credentials that
>    cover domain names or telephone numbers.  These credentials may
>    represent authority over an entire domain (such as example.com) or
>    potentially a set of domains enumerated by the credential.

[potentially] remove

The implication is that "a set of domains" is not "an entire domain", 
but I don't understand how the language says that.  As written, this 
actually translates to something like: authority over one or more 
domains.  Possibly what was meant is something like:  authority over an 
entire domain, or some number of sub-domains under that higher-level domain.

>    Similarly, a credential may represent authority over a single
>    telephone number or a range of telephone numbers.  The way that the

       Similarly for telephone numbers, a credential can represent one 
or a range of numbers.

>    scope of a credential is expressed is specific to the credential
>    mechanism.

So, there is no standard for the specification of credentials, here. 
That means that the technical details -- as distinct from the 
operational policies -- of credentials are out of scope, although they 
are fundamental to proper operation of this serve.  This is a 
showstopper, in terms of specification completeness for the service.

The following paragraph is not about credentials.  It is about signing 
policy.  It belongs elsewhere.  And since it isn't really specifying 
anything, that elsewhere probably is up towards introductory text.

>    Authorization of the use of a particular username or telephone number
>    in the identity field is a matter of local policy for the
>    authentication service, one that depends greatly on the manner in

Huh?

But really, when a specification says something is out of scope and is a 
matter for local policy, the specification should not then go on to 
specify examples of local policy.  In those cases where there is a 
compelling benefit to include such examples, put them in an appendix. 
But please, then, explain that compelling benefit.

>    which authentication is performed.  For non-telephone number user
>    parts, one policy might be as follows: the username given in the
>    'username' parameter of the Proxy-Authorization header MUST
>    correspond exactly to the username in the From header field of the
>    SIP message.  However, there are many cases in which this is too
>    limiting or inappropriate; a realm might use 'username' parameters in
>    Proxy-Authorization that do not correspond to the user-portion of SIP
>    From headers, or a user might manage multiple accounts in the same
>    administrative domain.  In this latter case, a domain might maintain
>    a mapping between the values in the 'username' parameter of Proxy-
>    Authorization and a set of one or more SIP URIs that might
>    legitimately be asserted for that 'username'.  For example, the
>    username can correspond to the 'private identity' as defined in Third
>    Generation Partnership Project (3GPP), in which case the From header
>    field can contain any one of the public identities associated with
>    this private identity.  In this instance, another policy might be as
>    follows: the URI in the From header field MUST correspond exactly to
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 13]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    one of the mapped URIs associated with the 'username' given in the
>    Proxy-Authorization header.  This is a suitable approach for
>    telephone numbers in particular.
>
>    This specification could also be used with credentials that cover a
>    single name or URI, such as [email-masked] or
>    sip:[email-masked].  This would require a modification to
>    authentication service behavior to operate on a whole URI rather than
>    a domain name.  Because this is not believed to be a pressing use
>    case, this is deferred to future work, but implementers should note
>    this as a possible future direction.
>
>    Exceptions to such authentication service policies arise for cases
>    like anonymity; if the AoR asserted in the From header field uses a
>    form like 'sip:[email-masked]' (see [RFC3323]), then the
>    'example.com' proxy might authenticate only that the user is a valid
>    user in the domain and insert the signature over the From header
>    field as usual.
>
> 6.2.  Credential Use by the Verification Service
>
>    In order to act as a verification service, a SIP entity must have a
>    way to acquire and retain credentials for authorities over particular

      for -> from  ?

>    domain names and/or telephone numbers or number ranges.
>    Dereferencing the URI found in the "info" parameter of the Identity
>    header (as described in the next section) MUST be supported by all

forward reference

>    verification service implementations to create a baseline means of

I /really/ don't understand the trust model that has a security scheme 
where the object giving a pointer to its own credential.  Or rather, I 
fear that I do understand it, but don't understand why its considered 
credible.

>    credential acquisition.  Provided that the credential used to sign a
>    message is not previously known to the verifier, SIP entities SHOULD
>    discover this credential by dereferencing the "info" parameter,
>    unless they have some more other implementation-specific way of
>    acquiring the needed keying material, such as an offline store of
>    periodically-updated credentials.  If the URI in the "info" parameter
>    cannot be dereferenced, then a 436 'Bad Identity-Info' response MUST
>    be returned.

Again, this much non-determinacy in such an essential mechanism ensures 
/non-/interoperability.  I do understand the intent to have 
private/proprietary mechanism at work for use of this spec back in the 
regulated telecom space, but that does not mean it needs to distract the 
public specification.  A complete specification of a STIR service needs 
to include a publicly-usable key certification mechanism, a la DANE or 
DKIM or the like.

The application of STIR for other, non-open operations are always free 
to amend the specification through a separate profile that overrides one 
or another piece of the base STIR specifications.

>
>    This specification does not propose any particular policy for a
>    verification service to determine whether or not the holder of a
>    credential is the appropriate party to sign for a given SIP identity.

This is a fundamental flaw in this specification.  It reduces to saying 
that the document is specifying a validation service that does not 
provide a deterministic means for assessing validation.

>    Guidance on this is deferred to the credential mechanism
>    specifications, which must meet the requirements in Section 6.4.
>
>    Verification service implementations supporting this specification
>    may wish to have some means of retaining credentials (in accordance
>    with normal practices for credential lifetimes and revocation) in
>    order to prevent themselves from needlessly downloading the same
>    credential every time a request from the same identity is received.
>    Credentials cached in this manner may be indexed in accordance with

This is gratuitous implementation advice.  Remove it.

If there is a compelling desire to give implementation advice, move it 
to a separate document and make it more complete.

It is especially ironic to try to give implementation advice about a 
mechanism that isn't fully specified.

>
> Peterson, et al.         Expires January 8, 2017               [Page 14]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    local policy: for example, by their scope, or the URI given in the
>    "info" parameter value.  Further consideration of how to cache
>    credentials is deferred to the credential mechanism specifications.
>
> 6.3.  Handling 'info' parameter URIs

I don't find a specification for the 'info' parameter.  I find many 
references to the Identity-Info header field, but assume that's not what 
is meant here.

I also find abnf for an ident-info rule, which includes an "ident" 
literal string.  I suspect this is the reference you intend?

Please reference these more formally and properly cite their definition 
at first use.  (If you want to rename rules, to make the use of the 
rulename more pleasant in the text, that's fine.  But just make sure 
that a new reader can understand what type of reference is being made 
and where to go to find its definition.

Ditto for "alg".

Ditto for ppt.

And, of course, these are more forward references.  In this case, it's 
giving detail about something that hasn't even been defined yet.

>    An "info" parameter MUST contain a URI which dereferences to a

This isn't about the handling of info.  It's defining its contents. They 
need to be separate segments of text.

>    resource that contains the public key components of the credential
>    used by the authentication service to sign a request.  It is
>    essential that a URI in the "info parameter" be dereferencable by any

Again, specification, not handling.  Also, what do the instructions 
mean?  How is the signer to know what is dereferenceable by the verifier?

>    entity that could plausibly receive the request.  For common cases,
>    this means that the URI must be dereferencable by any entity on the
>    public Internet.  In constrained deployment environments, a service
>    private to the environment might be used instead.
>
>    Beyond providing a means of accessing credentials for an identity,
>    the "info" parameter further serves as a means of differentiating
>    which particular credential was used to sign a request, when there
>    are potentially multiple authorities eligible to sign.  For example,

It sounds as if the real need is to have an external registry of 
authorized credentialing services and then refer to the one that is used 
by name.  That provides independent vetting and limits the 'vocabulary' 
of credential service references the message can cite.

>    imagine a case where a domain implements the authentication service
>    role for a range of telephone and a user agent belonging to Alice has
>    acquired a credential for a single telephone number within that
>    range.  Either would be eligible to sign a SIP request for the number
>    in question.  Verification services however need a means to
>    differentiate which one performed the signature.  The "info"
>    parameter performs that function.
>
> 6.4.  Credential System Requirements

Besides having extraneous material, this section is almost certainly 
incomplete and probably extremely incomplete.  I suggest removing the 
section and simply state that the details of the credentialing system 
are outside the scope of this specification, except for specifying a 
registry that lists possible systems.

Also note that the claimed interest in authentication beyond SIP will 
also require credentialing systems.  As such, the entire topic appears 
to be larger than this specification.

>    This document makes no recommendation for the use of any specific
>    credential system.  Today, there are two primary credential systems

A review of current, external services and hypothetical capabilities is 
not appropriate for inclusion inside a technical specification.  Move it 
to a separate document.

>    in place for proving ownership of domain names: certificates (e.g.,
>    X.509 v3, see [RFC5280]) and the domain name system itself (e.g.,
>    DANE, see [RFC6698]).  It is envisioned that either could be used in
>    the SIP identity context: an "info" parameter could for example give
>    an HTTP URL of the Content-Type 'application/pkix-cert' pointing to a
>    certificate (following the conventions of [RFC2585]).  The "info"
>    parameter may use the DNS URL scheme (see [RFC4501]) to designate
>    keys in the DNS.
>
>    While no comparable public credentials exist for telephone numbers,
>    either approach could be applied to telephone numbers.  A credential
>    system based on certificates is given in
>    [I-D.ietf-stir-certificates], but this specification can work with
>    other credential systems; for example, using the DNS was proposed in
>    [I-D.kaplan-stir-cider].

the above isn't 'requirements'.
>
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 15]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    In order for a credential system to work with this mechanism, its
>    specification must detail:
>
>       which URIs schemes the credential will use in the "info"
>       parameter, and any special procedures required to dereference the
>       URIs
>
>       how the verifier can learn the scope of the credential

what does scope of the credential'?

>       any special procedures required to extract keying material from
>       the resources designated by the URI
>
>       any algorithms required to validate the credentials (e.g. for
>       certificates, any algorithms used by certificate authorities to
>       sign certificates themselves)

Looks like this needs to define a STIR Credential Registry.

>    It is furthermore required that all credential specifications
>    describe how the associated credentials will support the mandatory
>    signing algorithm(s) required by PASSporT [I-D.ietf-stir-passport].

So this really is another bullet for the above, indented list?

Then again:  credentials supporting signing algorithms?  I don't 
understand this.  The signing algorithms are for the payload using the 
key /from/ the credential.  So what does this requirement mean, and why?

>
>    SIP entities cannot reliably predict where SIP requests will
>    terminate.  When choosing a credential scheme for deployments of this
>    specification, it is therefore essential that the trust anchor(s) for
>    credentials be widely trusted, or that deployments restrict the use
>    of this mechanism to environments where the reliance on particular
>    trust anchors is assured by business arrangements or similar
>    constraints.

      replace above with:  Use of a credentialing mechanism must be 
supported within a scope sufficient to include the authentication 
service, the verifying service and the credentialing service.

>
>    Note that credential systems must address key lifecycle management
>    concerns: were a domain to change the credential available at the
>    Identity-Info URI before a verifier evaluates a request signed by an
>    authentication service, this would cause obvious verifier failures.
>    When a rollover occurs, authentication services SHOULD thus provide
>    new Identity-Info URIs for each new credential, and SHOULD continue
>    to make older key acquisition URIs available for a duration longer
>    than the plausible lifetime of a SIP transaction (a minute would most
>    likely suffice).
>
> 7.  Identity Types
>
>    This specification focuses primarily on cases where the called and

Focuses primarily?  What I've been reading in this spec covers both 
phone and uri forms.  So I don't know what the 'primarily' refers to.

>    calling parties identified in the To and From header field values use
>    telephone numbers, as this remains the dominant use case in the
>    deployment of SIP.  However, this specification also works with
>    "greenfield" identifiers (of the form "sip:user@host"), and
>    potentially other identifiers when SIP interworks with another
>    protocol.

What about these is 'greenfield'?  What does it mean here?

>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 16]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    The guidance in this section also applies to extracting the URI

guidance vs. specification?

>    containing the originator's identity from the P-Asserted-Identity
>    header field value instead of the From header field value.  In some

Huh?  How is the verifier supposed to know where to draw the values from?

>    environments, the P-Asserted-Identity header field is used in lieu of
>    the From header field to convey the address-of-record or telephone
>    number of the sender of a request; while it is not envisioned that
>    many of those networks would or should make use of the Identity
>    mechanism described in this specification, where they do, local
>    policy might therefore dictate that the canonical identity derive
>    from the P-Asserted-Identity header field rather than the From.

As soon as a document says 'local policy' it needs to stop specifying 
detail, since it is both outside of the scope of the document and it is 
distracting from the details of the specification.

If you have to make reference to the possibility, then include something 
simple and brief, such as:

      Local policies might choose to use a value from fields other than 
To and From.  The details for this are outside the scope of this 
specification.

To the extent there is a compelling need to specify this alternative 
mechanism, do it in a separate specification.

>    Ultimately, in any case where local policy canonicalizes the idenity
>    into a form different from how it appears in the From header field,
>    the use of the "canon" parameter by authentication services is
>    RECOMMENDED, but because "canon" itself could then divulge
>    information about users or networks, implementers should be mindful
>    of the guidelines in Section 11.

remove above paragraph.

>
>    It may not be trivial to tell if a given URI contains a telephone

If that means it isn't deterministic, we've got a basic problem, since 
protocol specs do not offer heuristics.

If it just means there is complexity, then the sentence says nothing useful.

>    number.  In order to determine whether or not the user portion of a

     [or not] remove

>    SIP URI is a telephone number, authentication services and
>    verification services MUST perform the following procedure on any SIP
>    URI they inspect which contains a numeric user part.  Note that the
>    same procedures are followed for creating the canonical form of URIs
>    found in the From header field as they are in the To header field or
>    the P-Asserted-Identity header field.

If there is an algorithm to follow, specify it as an algorithm. 
Otherwise, this is non-normative discussion and isn't very helpful here.

>    First, implementations must look for obvious indications that the
>    user-portion of the URI constitutes a telephone number.  Telephone
>    numbers most commonly appear in SIP header field values in the

"most commonly" suggests that this is discussion, not specification.

>    username portion of a SIP URI (e.g.,
>    'sip:[email-masked];user=phone').  The user part of
>    that URI conforms to the syntax of the TEL URI scheme (RFC 3966
>    [RFC3966]).  It is also possible for a TEL URI to appear in the SIP
>    To or From header field outside the context of a SIP or SIPS URI
>    (e.g., 'tel:+17005551008').  Thus, in some environments, numbers will
>    be explicitly labeled by the use of TEL URIs or the 'user=phone'
>    parameter, or implicitly by the presence of the '+' indicator at the
>    start of the user-portion.  Absent these indications, if there are
>    numbers present in the user-portion, implementations may also detect
>    that the user-portion of the URI contains a telephone number by
>    determining whether or not those numbers would be dialable or
>    routable in the local environment -- bearing in mind that the
>    telephone number may be a valid E.164 number, a nationally-specific
>    number, or even a private branch exchange number.  Once a telephone
>    number has been detected, implementations should follow the
>    procedures in Section 7.2.
>
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 17]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    If the URI field does not contain a telephone number, URI
>    normalization procedures are invoked to canonicalize the URI before
>    it is included in a PASSporT object in, for example, an "uri" claim.
>    See Section 7.4 for that behavior.

I suspect that the above topic is confusing what can/must be done as a 
deterministic specification, with what incremental value can be obtained 
by the addition of some non-normative heuristics.  Separate these and 
make the deterministic stuff part of the specification and the 
heuristics part of an external document discussing real-world 
implementation, or somesuch.

> 7.1.  Authority for Telephone Numbers
>
>    In order for telephone numbers to be used with the mechanism
>    described in this document, authentication services must enroll with
>    an authority that issues credentials authoritative for telephone
>    numbers or telephone number ranges, and verification services must
>    trust the authority employed by the authentication service that signs

"enroll"???

>    a request.  Per Section 6.4, enrollment procedures and credential
>    management are outside the scope of this document; approaches to
>    credential management for telephone numbers are discussed in
>    [I-D.ietf-stir-certificates].

If they are outside the scope, then don't provide details such as about 
enrolling.  At the least, don't repeat information provided elsewhere in 
the document.

>
> 7.2.  Telephone Number Canonicalization Procedures
>
>    Once an implementation has identified a telephone number in the URI,

    Once a telephone number is identified...

And what about telephone numbers that are not part of a URI?

>    it must construct a number string.  That requires performing the
>    following steps:

If a 'number string' has been identified, then what does it mean to 
'construct a number string'?  I think what's meant is that it is 
necessary to put the number into a canonical form.  In any case, please 
clarify what is meant.

The algorithm should be specified in the form of an algorithm, rather 
than as normative prose, and language like "except only" encourages 
coding errors:

>       Implementations MUST drop any leading +'s, any internal dashes,
>       parentheses or other non-numeric characters, excepting only the
>       leading "#" or "*" keys used in some special service numbers
>       (typically, these will appear only in the To header field value).
>       This MUST result in an ASCII string limited to "#", "*" and digits
>       without whitespace or visual separators.

So '+' is retained if it's internal?  Why?

Move commentary about the algorithm -- such as "these will appear..." -- 
to be outside of the algorithm specification.

>       Next, an implementation must assess if the number string is a
>       valid, globally-routable number with a leading country code.  If

How are they to do this?

>       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

So, again, this isn't really a specification.  Language like 'may 
involve' makes this commentary.

>       national or international dialing prefixes or performing similar
>       procedures.  It is only in the case that an implementation cannot
>       determine how to convert the number to a globally-routable format

Again, this kind of language is not really a specification.

>       that this step may be skipped.  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.
>
>       Other transformations during canonicalization MAY be made in
>       accordance with specific policies used within a local domain.  For
>       example, one domain may only use local number formatting and need
>       to convert all To/From user portions to E.164 by prepending

And the above text also is not a specification.  It also isn't 
interoperable.  It says "the folks encoding the strings will do whatever 
local stuff they feel like and the folks at the verification side won't 
know what it was and won't be able to replicate it.  So canonicalization 
won't be a standard, global service.

The alternative model, is that 'local policy' will be the same for both 
ends, in which case, the spec is saying that there might be 
canonicalizations that are outside the specifications.  But in that 
case, text referring to it is distracting rather than helpful.

If a local environment is doing 'local policy' then it will document 
that separately.  There is no utility in making vague statements about 
possibilities that are outside the spec.

>
>
> Peterson, et al.         Expires January 8, 2017               [Page 18]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>       country-code and region code digits; another domain might prefix
>       usernames with trunk-routing codes and need to remove the prefix.
>       This specification cannot anticipate all of the potential
>       transformations that might be useful.
>
>       The resulting canonical number string will be used as input to the
>       hash calculation during signing and verifying processes.
>
>    The ABNF of this number string is:
>
>              tn-spec = [ "#" / "*" ] 1*DIGIT

I suspect that the entire topic of canonicalization merely needs core 
text that says somethg like:

     Take the original string and remove any characters that do not 
conform to the above format.

Then tweak that text for any cases that need to add characters.

>
>    If the result of this procedure forms a complete telephone number,

What is the definition of a 'complete tn'?  Cite it.

>    that number is used for the purpose of creating and signing the

      for the purpose of creating and signing -> for creating

I suspect it is /not/ used "for signing" but is in fact used to create 
part of the content that is signed.  That's different.

>    signed-identity-string by both the authentication service and
>    verification service.  Practically, entities that perform the
>    authentication service role will sometimes alter the telephone
>    numbers that appear in the To and From header field values,
>    converting them to this format (though note this is not a function
>    that [RFC3261] permits proxy servers to perform).  The result of the
>    canonicalization process of the From header field value may also be
>    recorded through the use of the "canon" parameter of the Identity(see
>    Section 8).

Why is this significant?  How does it affect processing?

>
>    If the result of the canonicalization of the From header field value
>    does not form a complete and valid telephone number, the
>    authentication service and/or verification service SHOULD treat the
>    entire URI as a SIP URI, and apply the procedures in Section 7.4.

Here, having a SHOULD rather than a MUST seems likely to produce 
non-interoperability, since signer and validator are allowed to behave 
differently, thereby making it likely they will produce different results.

>
> 7.3.  Authority for Domain Names

Authority for domain names comes from ICANN.  Unfortunately, I'm not 
clear enough about the specific purpose of this section, but it needs a 
title that is more specific and clear.

It appears that this section is both trying to give background about 
various occurrences of domain names and (redundantly?) discuss the 
challenges of finding the right caller-id string.  This suggests 
splitting the discussion to an earlier, non-normative section, and a 
section here that simply specifies technical detail to perform.

>    When a verifier processes a request containing an Identity-Info
>    header with a domain signature, it must compare the domain portion of

must or MUST?

>    the URI in the From header field of the request with the domain name
>    that is the subject of the credential acquired from the "info"
>    parameter.  While it might seem that this should be a straightforward
>    process, it is complicated by two deployment realities.  In the first
>    place, credentials have varying ways of describing their subjects,
>    and may indeed have multiple subjects, especially in 'virtual
>    hosting' cases where multiple domains are managed by a single
>    application.  Secondly, some SIP services may delegate SIP functions
>    to a subordinate domain and utilize the procedures in RFC 3263
>    [RFC3263] that allow requests for, say, 'example.com' to be routed to
>    'sip.example.com'.  As a result, a user with the AoR
>    'sip:[email-masked]' may process requests through a host like
>    'sip.example.com', and it may be that latter host that acts as an
>    authentication service.
>

But since credentials are a modularized construct, outside of this 
specification, why is this specification going into this sort of detail 
about them?

>
> Peterson, et al.         Expires January 8, 2017               [Page 19]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    To meet the second of these problems, a domain that deploys an
>    authentication service on a subordinate host MUST be willing to
>    supply that host with the private keying material associated with a
>    credential whose subject is a domain name that corresponds to the
>    domain portion of the AoRs that the domain distributes to users.
>    Note that this corresponds to the comparable case of routing inbound
>    SIP requests to a domain.  When the NAPTR and SRV procedures of RFC
>    3263 are used to direct requests to a domain name other than the
>    domain in the original Request-URI (e.g., for 'sip:[email-masked]',
>    the corresponding SRV records point to the service
>    'sip1.example.org'), the client expects that the certificate passed
>    back in any TLS exchange with that host will correspond exactly with
>    the domain of the original Request-URI, not the domain name of the
>    host.  Consequently, in order to make inbound routing to such SIP
>    services work, a domain administrator must similarly be willing to
>    share the domain's private key with the service.  This design
>    decision was made to compensate for the insecurity of the DNS, and it
>    makes certain potential approaches to DNS-based 'virtual hosting'
>    unsecurable for SIP in environments where domain administrators are
>    unwilling to share keys with hosting services.

Really, I suspect all of the above detail is out of scope, given the way 
these specifications have been partitioned.

>
>    A verifier MUST evaluate the correspondence between the user's
>    identity and the signing credential by following the procedures
>    defined in RFC 2818 [RFC2818], Section 3.1.  While RFC 2818 [RFC2818]
>    deals with the use of HTTP in TLS and is specific to certificates,
>    the procedures described are applicable to verifying identity if one
>    substitutes the "hostname of the server" in HTTP for the domain
>    portion of the user's identity in the From header field of a SIP
>    request with an Identity header.

What does 'must evaluate' mean?  What specific 'evaluation' actions are 
being required?  And actions are to be taken in response to the evaluation?

> 7.4.  URI Normalization

Canonicalization for phone numbers and Normalization for URI.  Why the 
difference?

>    Just as telephone numbers may undergo a number of syntactic
>    transformation during transit, the same can happen to SIP and SIPS

   transformation  -> transformations

>    URIs without telephone numbers as they traverse certain
>    intermediaries.  Therefore, when generating a PASSporT object based
>    on a SIP request, any SIP and SIPS URIs must be transformed into a
>    canonical form which captures the address-of-record represented by
>    the URI before they are provisioned in PASSporT claims such as "uri".

The above text belongs in an earlier discussion of issues, so that the 
specification section can focus on specifying.

>    The URI normalization procedures required are as follows.
>
>    Following the ABNF of RFC3261, the SIP or SIPS URI in question MUST

Which ABNF?  Where in the document?  Section 25.1?

What about the ABNF requires any of what is asserted here?

Again, algorithms need to be specified as algorithms, not just prose.

>    discard all elements after the "hostport" of the URI, including all
>    uri-parameters and headers, from its ayntax.  Of the userinfo

"including"?  By my reading there isn't anything other than those two rules.

>    component of the SIP URI, only the user element will be retained: any
>    password (and any leading ":" before the password) MUST be removed,
>    and since this userinfo necessarily does not contain a telephone-

I think the algorithm intended here is:

    1. Parse the SIP/SIPS URI

    2. Retain <user> if present
       ; <telephone-subscriber> will not be present

    3. Retain <host>

    done.

> Peterson, et al.         Expires January 8, 2017               [Page 20]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    subscriber component, no further parameters can appear in the user
>    portion.
>
>    The hostport portion of the SIP or SIPS URI MUST similarly be
>    stripped of any trailing port along with the ":" that proceeds the
>    port, leaving only the host.

In other words, just get <host>

>
>    The ABNF of this canonical URI form (following the syntax defined in
>    RFC3261) is:
>
>              canon-uri =  ( "sip" / "sips" ) ":" user "@" host

What is the purpose of retaining the sip/sips distinction, within this 
context?

>    Finally, the URI will be subject to syntax-based URI normalization
>    procedures of [RFC3986] Section 6.2.2, especially to perform case

Except that 6.2.2 does not actually specify normalization.  Rather, it 
talks about an approach to normalization, without giving precise details.

>    normalization and percent-encoding normalization.  However, note that
>    normalization procedures face known challenges in some
>    internationalized environments (see [I-D.ietf-iri-comparison]) and
>    that perfect normalization of URIs may not be possible in those
>    environments.

The above last sentence reduces to: do normalization but don't rely on 
it working.

This again raises the question of treating a broken signature the same 
as no signature present.

>
>    For future PASSporT applications, it may be desirable to provide an
>    identifier without an attached protocol scheme.  Future

Discussion about future hypotheticals, again.  Remove.

>    specifications that define PASSporT claims for SIP as a using
>    protocol could use these basic procedures, but eliminate the scheme
>    component.  A more exact definition is left to future specifications.

Exactly.

> 8.  Header Syntax

I'm quite confused.  This section appears to be simultaneously 
specifying a SIP Identity header field as well as how to populate an 
associate Passort entity.

>    The Identity and Identity-Info headers that were previously defined

header *field*

>    in RFC4474 are deprecated.

Reference to the previous 4474 content is unproductive and distracting. 
Remove all of it.  This is a new specification.

It is not revising an installed base.  So this section should merely 
define what it defines and not put it in terms of the earlier document.

  This revised specification collapses the
>    grammar of Identity-Info into the Identity header via the "info"
>    parameter.  Note that unlike the prior specification in RFC4474, the
>    Identity header is now allowed to appear more than one time in a SIP
>    request.  The revised grammar for the Identity header is (following
>    the ABNF [RFC4234] in RFC 3261 [RFC3261]):
>
>    Identity = "Identity" HCOLON signed-identity-digest SEMI ident-info *( SEMI ident-info-params )
>    signed-identity-digest = LDQUOT *base64-char RDQUOT
>    ident-info = "info" EQUAL ident-info-uri
>    ident-info-uri = LAQUOT absoluteURI RAQUOT
>    ident-info-params = ident-info-alg / ident-type / canonical-str / ident-info-extension
>    ident-info-alg = "alg" EQUAL token
>    ident-type = "ppt" EQUAL token
>    canonical-str = "canon" EQUAL *base64-char
>    ident-info-extension = generic-param
>
>    base64-char = ALPHA / DIGIT / "/" / "+"

Note the use of ABNF here, rather than JSON.

canon is optional.  why doesn't the abnf show it as optional?  I suspect 
the issue is that the abnf needs to distinguish between mandatory and 
optional components of the Identity header field.

<token> isn't defined!!!

<generic-param> isn't defined.

LAQUOT, EQUAL, RAQUOT, absoluteURI are all undefined.  Rules like these 
are usually inherited from another document.  If that's the case here, 
cite it.

These sorts of rules (including base-64-char, which is defined 
syntactically but not semantically) need explicit ABNF rules with their 
names and then need prose text to explain their semantics.

>
> Peterson, et al.         Expires January 8, 2017               [Page 21]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    In addition to "info" parameter, and the "alg" parameter previously

    to -> to the

>    defined in RFC4474, this specification includes the optional "canon"
>    and "ppt" parameters.  Note that in RFC4474, the signed-identity-
>    digest (see ABNF above) was given as quoted 32LHEX, whereas here it
>    is given as a quoted sequence of base64-char.
>
>    The 'absoluteURI' portion of ident-info-uri MUST contain a URI; see
>    Section 6.3 for more on choosing how to advertise credentials through
>    this parameter.
>
>    The signed-identity-digest is the signed hash component of a PASSporT
>    object [I-D.ietf-stir-passport], a signature which PASSporT generates

That document does not contain the string "signed hash".  The word 
'hash' only appears in 3.2.2.2 "mky".  Worse, that section really does 
not specify its contents.  Rather -- yet again -- we get discussion 
about purpose and possibility.

Specific reference to a specific value that can be interoperably 
generated is needed.

>    over a pair of JSON objects.  The first PASSporT object contains

What is meant by "the first passport object"?  Where is there 
specification of multiple of them and how is their ordering determined?

>    header information, and the second contains claims, following the
>    conventions of JWT [RFC7519]; some header and claim values will
>    mirror elements of the SIP request.  Once these two JSON objects have

I've gone back and looked at the Passport references to "object" and do 
not see any clear indication that there are two, in the style being 
summarized here.  Note that Passport's Section 3.1 does not say 
"object".  Nor does the next section, 3.2.  Yet, apparently, both should.

But matters appear to be more confusing than that, in the Passport 
document, such as Section 3.2.2.1, which is titled 'claims' but makes 
references to objects.

I naturally assume that some portion of this is inherited from JSON 
and/or JWT, which is a nice example of the significant, additional 
overhead being being introduced with their use.  And in this case, 
apparently confusion.

>    been generated, they will be encoded, then hashed with a SHA-256
>    hash.  Those two hashes are then concatenated (header then claims)
>    into a string separated by a single "." per baseline PASSporT.
>    Finally, that string is signed to generate the signed-identity-digest
>    value of the Identity header.

Another algorithm needing to be specified as an algorithm.

>
>    For SIP implementations to populate the PASSporT header object from a
>    SIP request, the following elements message MUST be placed as the

placed where?

Or is this really a straight data copy from the JSON form to parameters 
in the SIP Identity header field?

>    values corresponding to the designated JSON keys:

Delete the opening clause.

>       First, per baseline [I-D.ietf-stir-passport], the JSON key "typ"
>       key MUST have the value "passport".

This appears to be introducing a redundancy between this spec and the 
Passport spec.  There needs to be language in one that merely cites the 
other, rather than respecifying it.

>
>       Second, the JSON key "alg" MUST mirror the value of the optional
>       "alg" parameter in the SIP Identity header.  Note if the "alg"
>       parameter is absent, the default value is "ES256".
>
>       Third, the JSON key "x5u" MUST have a value equivalent to the
>       quoted URI in the "info" parameter.
>
>       Fourth, the optional JSON key "ppt", if present, MUST have a value
>       equivalent to the quoted value of the "ppt" parameter of the
>       Identity header.  If the "ppt" parameter is absent from the
>       header, the "ppt" key MUST NOT not appear in the JSON heaer
>       object.

All of these 'must' formations are overkill.  Normally, algorithms are 
specified in a simple, declarative manner.

>    For example:
>
>    { "typ":"passport",
>      "alg":"ES256",
>      "x5u":"https://www.example.com/cert.pkx" }

What is this example demonstrating?  How is the reader to know?

>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 22]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    To populate the PASSporT claims JSON object from a SIP request, the
>    following elements MUST be placed as values corresponding to the
>    designated JSON keys:
>
>       First, the JSON "orig" array MUST be populated.  If the
>       originating identity is a telephone number, then the array MUST be
>       populated with a "tn" claim with a value set to the value of the
>       quoted originating identity, a canonicalized telephone number (see
>       Section 7.2).  Otherwise, the array MUST be populated with a "uri"
>       claim, set to the value of the AoR of the UA sending the message
>       as taken from addr-spec of the From header field, per the
>       procedures in Section 7.4.

Again, this appears to be quite a bit of detail that is redundant with 
specifications elsewhere.

>
>       Second, the JSON "dest" array MUST be populated.  If the
>       destination identity is a telephone number, then the array MUST be
>       populated with a "tn" claim with a value set to the value of the
>       quoted destination identity, a canonicalized telephone number (see
>       Section 7.2).  Otherwise, the array MUST be populated with a "uri"
>       claim, set to the value of the addr-spec component of the To
>       header field, which is the AoR to which the request is being sent,
>       per the procedures in Section 7.4.
>
>       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).
>
>       Fourth, if the request contains an SDP message body, and if that
>       SDP contains one or more "a=fingerprint" attributes, then the JSON
>       key "mky" MUST appear with the algorithm(s) and value(s) of the
>       fingerprint attributes (if they differ), following the format
>       given in [I-D.ietf-stir-passport] Section 3.2.2.2.
>
>    For example:
>
>       { "orig":{"tn":"12155551212"},
>         "dest":{"tn":"12155551213"},
>         "iat":"1443208345" }
>
>    For more information on the security properties of these SIP message

'more'?  is there security information here?  where?

>    elements, and why their inclusion mitigates replay attacks, see
>    Section 12 and [RFC3893].  Note that future extensions to the

And since every RFC contains a security considerations section, a 
generic reference like this, here, is of no obvious value.  It's just 
more text.

>    PASSporT object could introduce new claims, and that further SIP

Future reference to hypotheticals.

>    procedures could be required to extract further information from the
>    SIP request to populate the values of those claims; see Section 9.
>
>    The "orig" and "dest" arrays may contain identifiers of heterogeneous
>    type; for example, the "orig" array might contain a "tn" claim, while

What is the import of this observation?

Is there something in the specification that appears to constrain the 
choices?

>    the "dest" contains a "uri" claim.  Also note that in some cases, the
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 23]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    "orig" and "dest" arrays might be populated with more than one value.
>    This could for example occur when multiple "dest" identities are
>    specified in a meshed conference.  Defining how a SIP implementation
>    would provision multiple originating or destination identities is
>    left as a subject for future specification.
>
>    After these two JSON objects, the header and the claims, have been
>    constructed, they must each be hashed per [I-D.ietf-stir-passport]
>    Section 3.3.  The signed value of those concatenated hashes then

Except that Passport Section 3.3 says nothing more than:

      The signature of the PASSporT is created as specified by JWS using
    the private key corresponding to the X.509 public key certificate
    referenced by the "x5u" header parameter.

and that doesn't look like an implementable specification to me.

>    becomes the signed-identity-string of the Identity header.  The
>    hashing and signing algorithm is specified by the 'alg' parameter of
>    the Identity header and the mirrored "alg" parameter of PASSporT.
>    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.
>
>    The complete form of the Identity header will therefore look like the
>    following example:
>
>   Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
>       eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
>       pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \
>           info=<https://biloxi.example.org/biloxi.cer>;alg=ES256

It would be quite a bit more helpful to have a detail, incremental 
example that shows how each of the bits are created and then assembled.

>    In a departure from JWT practice, the SIP usage of PASSporT MAY NOT
>    include the base64 encoded version of the JSON objects in the

JWT normally calls for including the encoded version of JSON objects in 
the Identity header (field)?

Really, it isn't clear what the exact exception is.  If citing this is 
that important, please make the details clear including appropriate 
citations, such as to the relevant part of the JWT spec.

>    Identity header: only the signature component of the PASSporT is
>    REQUIRED.  Optionally, as a debugging measure or optimization, the
>    base64 encoded concatenation of the JSON header and claims may be
>    included as the value of a "canon" parameter of the Identity header.
>    Note that this may be lengthy string.
>
> 9.  Extensibility
>
>    For the extensibility of baseline PASSporT with now claims, see
>    [I-D.ietf-stir-passport] Section 4.

"with now claims"?

And what is the benefit of having this directive?

>
>    As future requirements may warrant increasing the scope of the
>    Identity mechanism, this specification defines an optional "ppt"
>    parameter of the Identity header, which mirrors the "ppt" header key

The term 'header key' does not occur in the Passport specifiction. 
Perhaps this is meant to refer to that doc's section 4.1 header parameter?

>    in PASSporT.  The "ppt" parameter value MUST consist of a token
>    containing an extension specification, which denotes an extended set
>    of one or more signed claims per the type extensibility mechanism
>    specified in [I-D.ietf-stir-passport].

So they will only be able to use one extension?

Also, what is the utility of having this information in the SIP Identity 
header field?

>
>
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 24]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    An authentication service cannot assume that verifiers will
>    understand any given extension.  Verifiers that do support an
>    extension may then trigger appropriate application-level behavior in
>    the presence of an extension; authors of extensions should provide
>    appropriate extension-specific guidance to application developers on
>    this point.

This is likely redundant information.

>
>    If any claim in an extension contains a JSON value that does not
>    correspond to any field of the SIP request, but then the optional
>    "canon" parameter MUST be used for the Identity header containing
>    that extension.

   If...but then  appears to be a non-sequitor or incompletely 
formulated sentence.

>
> 10.  Backwards Compatibililty with RFC4474

Delete this section.

>    This specification introduces several significant changes from the
>    RFC4474 version of the Identity header.  However, due to the problems
>    enumerated in [I-D.rosenberg-sip-rfc4474-concerns], it is not
>    believed that the original Identity header has seen any deployment,
>    or even implementation in deployed products.
>
>    As such, this mechanism contains no provisions for signatures
>    generated with this specification to work with RFC4474-compliant
>    implementations, nor any related backwards-compatibility provisions.
>    Hypothetically, were an RFC4474-compliant implementation to receive
>    messages containing this revised version of the Identity header, it
>    would likely fail the request due to the absence of an Identity-Info
>    header with a 436 response code.  Implementations of this
>    specification, for debugging purposes, might interpret a 436 with a
>    reason phrase of "Bad Identity-Info" as an indication that the
>    request has failed because it reached a (hypothetical)
>    RFC4474-compliant verification service.

In fact there is so little overlap of substantive text, this really is 
an entirely new document and not a bis.

> 11.  Privacy Considerations
>
>    The purpose of this mechanism is to provide a strong identification

I think the usual terms are 'strong authentication' or 'strong security' 
(though 'security' has no clear technical meaning.)  'Strong 
identification' appears to have no common meaning.

>    of the originator of a SIP request, specifically a cryptographic
>    assurance that an authority asserts the originator can claim the URI
>    given in the From header field.  This URI may contain a variety of
>    personally identifying information, including the name of a human
>    being, their place of work or service provider, and possibly further
>    details.  The intrinsic privacy risks associated with that URI are,
>    however, no different from those of baseline SIP.  Per the guidance
>    in [RFC6973], implementers should make users aware of the privacy
>    trade-off of providing secure identity.
>
>    The identity mechanism presented in this document is compatible with
>    the standard SIP practices for privacy described in [RFC3323].  A SIP
>    proxy server can act both as a privacy service and as an

I think that I don't know what it means to be a 'privacy service'.  What 
functionality does this reference here and how is the reader to know?

>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 25]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    authentication service.  Since a user agent can provide any From
>    header field value that the authentication service is willing to
>    authorize, there is no reason why private SIP URIs that contain
>    legitimate domains (e.g., sip:[email-masked]) cannot be signed

This sentence sounds as if it is signaling an important point, but the 
text does not make clear what that import is.  My guess is that it needs 
to be preceded by a sentence that explains what problem the reader might 
think exists.  Then this text explains that it doesn't.

>    by an authentication service.  The construction of the Identity
>    header is the same for private URIs as it is for any other sort of

How is that a privacy matter?

>    URIs.  Similar practices could be used to support opportunistic
>    signing of SIP requests for UA-integrated authentications services
>    with self-signed certificates, though that is outside the scope of
>    this specification and is left as a matter for future investigation.
>
>    Note, however, that even when using anonymous SIP URIs, an
>    authentication service must possess a certificate corresponding to
>    the host portion of the addr-spec of the From header field of the

The 'however' does not follow any statement that it matches against. 
Again, there's no stage that has been set, for which this resolves a 
concern.

>    request; accordingly, using domains like 'anonymous.invalid' will not

if this is actually a domain value that is used, please cite where it is 
documented.  For that matter, how is one to tell what other domains are 
'like' it?  If the string isn't in actual use then why doesn't it use 
the usual RFC choices for an example domain name?

>    be possible for privacy services that also act as authentication
>    services.  The assurance offered by the usage of anonymous URIs with
>    a valid domain portion is "this is a known user in my domain that I
>    have authenticated, but I am keeping its identity private".

...

-- 

            Dave Crocker
            Brandenburg InternetWorking
            bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 9 Aug 2016 00:57:41 -0700

I'm responding to Jon's fair question of how much support there is for implementing the changes proposed by Dave.

I've only been able to make it around 1/2 of the way through Dave's comments.  My detailed reactions to these are inline below.

In summary, I believe that the majority of comments, if accepted, would substantially improve the doc.  A number of them address areas that were confusing to me on first reading of the draft, as well at least one point that I independently believed to be just plain wrong, detracting from the overall credibility of the doc.  There are also some nits, some comments that I do not agree with, and others that I have expanded upon below.

In any document there is always room for improvement.  However, at some point a group's edits reach a point at which there is little further improvement and the value of continued edits is low.  I do not believe that the draft is yet at this point.

Consistent with the goal of producing a sound, clear and precise RFC in a reasonable amount of time, I humbly suggest that careful evaluation and incorporation of Dave's (and others') comments where appropriate would be beneficial, and there are many (though likely not all) that could be addressed without major delay.  That said, it is clear that an RFC is needed sooner rather than later, and it makes sense to be mindful that delays from going back to the drawing board on some issues may result in a cure not worth the delay.  But these deserve at least a response to that effect.

Many thanks to all the parties for their editing and comments on what promises to be a highly impactful suite of RFCs.

Regards,

Alex

> -----Original Message-----
> From: stir [mailto:[email-masked]] On Behalf Of Dave Crocker
> Sent: Monday, August 8, 2016 8:46 PM
> To: [email-masked]
> Subject: [stir] Review of: draft-ietf-stir-rfc4474bis-10
>
>
>
This is a point of extreme importance.  There are much simpler mechanisms of distributing public keys for signature validation, assuming connectivity (e.g., via internet) to a suitable public key repository (e.g., ENUM, which seems to be trusted well enough to route calls by).  If I understand this correctly, certs are used to facilitate offline validation, an edge case, with the addition of considerable complexity (certs and associated infrastructure).  A much simpler and tested mechanism is used in DKIM/DMARC.
> picture, before diving into the detail of those to-be-integrated pieces.
That identity management is enhanced is true.  That it adds a new identity management mechanism is clearer.
> Introduction, but really it would be better to split them.
True, and it would be beneficial to split them.

Further, it would be beneficial to add that one of the most important benefits of authenticated identity is to provide a foundation for reputation-based policies.  Given that identities (e.g., phone numbers) are highly accessible and can be obtained anonymously (i.e., without a validated identity readily traceable to a person) in bulk, knowing that an identity isn't spoofed is generally insufficient information to establish whether a call is legal and non-abusive, or illegal or abusive.    One of the problems with the introductory sections is that they foster a mistaken belief that secure caller ID will solve the robocall problem.  As we know, it only even attempts to solve the spoofing problem.  It's a part of the solution.
> add:  Hence the foundation to accurate authorization is valid
This is a true statement of the philosophy behind this spec.  However, there are many cases in the current telephony system where it is unrealistic to expect authentication before authorization.
>            ...enables an authentication capability for protecting against...
No strong opinion here
> It likely will validate them in multiple places, including incoming
The current text I found confusing, and on my first reading of the doc had to read the sentence three times to understand it.  The intended perspective (e.g., of the call originator) is unclear.  I _initially_ fell into the trap of thinking that "incoming" was from the perspective of the terminating service provider.
> operator?  the term is ambiguous.
I do not have a problem here.  Yes, it's ambiguous, but I suspect that this ambiguity may be intentional.
> >    of a particular identity has been authorized.  A "verification
The sentence above is most intelligible when the three steps are distinctly listed in order, probably in three sentences for highest clarity:  Authentication, determination of authority, and finally signature computation/appending.
> alice@ discussion is for a SIP URI, but the text should make this explicit.
Yes this would be clearer
> >    those JSON object in a manner following PASSporT.  That signature is
a nit that needs correction
Also, "following" is probably not the best word choice
> Also, where is the object?  How is it created? How is it conveyed?
On my first read, I felt this was a hole that I needed to dive into (and did - I put down STIR and dove into other IDs).  It would be easier for the reader if some of these questions were answered.
> of the overall service and its components could be quite helpful.
APIWATW
> I'm not exactly sure what this means or is supposed to mean, but I
I, too, reacted very negatively to the word "obviously" on my first read of the spec.  It's not strictly true IMO, but this is an informative rather than normative section.  I think I submitted a comment to that effect that it's false and better to say 'typically' or 'often' instead (not sure if I ever sent that one, however).
> section rather than changing it's substance.
+1  It's typical use scenarios (examples).
> provide a deterministic means for assessing validation.
Is this truly a flaw or a feature?  Something that struck me as much or more than any introductory words to any RFC I've read are the first sentence of RFC6376:    "DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization that owns the signing domain to claim some
   _responsibility_ for a message by associating the domain with the
   message."

There's _ENORMOUS_ value to this (DKIM's) association of message with signer, arguably as much or more as the conveyance of trusted caller authentication.

IMHO, STIR would be more modular if it said less about what the signatures mean and left the door more open to additional/alternative signing mechanisms.  Having these in other specs or future revisions may help future proof this doc and assist in modularization.
> This is gratuitous implementation advice.  Remove it.
Generally, I agree.  Possible exception is a note that any cache mechanism implementations should consider impact on cert revocation timelines.  This might help the casual reader, but it's difficult to expect any competent cache designer to need this advice.
> >   Identity:
> "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkW
> zo
> >
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 9 Aug 2016 13:52:15 +0000

>I'm responding to Jon's fair question of how much support there is for
>implementing the changes proposed by Dave.

Well, I asked that about the changes he proposed to stir-passport, not to
rfc4474bis - the latter hadn't been sent to the list when I posed the
question.

>In summary, I believe that the majority of comments, if accepted, would
>substantially improve the doc.

Also, I posed my question in connection with the set of issues that Dave
had identified as substantial, non-blocking issues with PASSporT, rather
than minor changes that might improve readability or clarify technical
principles. I am not proposing to ignore those. In fact, if you go back to
my initial response to Dave's review of stir-passport:

https://www.ietf.org/mail-archive/web/stir/current/msg02478.html

... I say that many of Dave's suggestions for that document make a lot of
sense to me, and I promise that Chris and I will go through and implement
them where appropriate. I'm sure the same will be true for Dave's review
of rfc4474bis.

But as your point out in your note, other of these comments are not
offered with a mind to improving the document or advancing the work of
STIR. I've long since learned that the price of doing business in an open
standards body is identifying the useful comments that are often buried in
a heap of obstructionism or personal animus. That is what it is  - like I
said, sifting through material like this is part of the cost of doing
Internet standards in an open fashion, and the alternative would lead to
work of lesser quality.

The question I posed about the stir-passport review concerned the more
fundamental reconsiderations of the STIR architecture that Dave is
proposing, and the support or lack thereof for that set of objections
among working group participants. Since Dave refused to identify which of
his issues were blocking, I could only allude to them indirectly.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 07:12:10 -0700

On 8/9/2016 6:52 AM, Peterson, Jon wrote:
> and I promise that Chris and I will go through and implement
> them where appropriate.

This is the nugget of the process problem I was anticipating and seeking 
to resolve:

    This is a working group, not a cheerleading section for some 
authors.  In the IETF work is supposed to reflect the understanding and 
agreement of the working group.  The nature and extent of the problems 
I'm seeing with these documents suggests a significant lack of that 
shared effort.

    In some cases, a document really comes from and remains primarily 
the souls of the authors and the wg simply provides a surrounding sanity 
check.  That's fine, when the sanity check is meaningful.  But these 
documents don't have that kind of history or nature.

    A process in which the authors take extensive comments and go into a 
back room and decide on their own what to do with them is a deviation 
from the pure IETF model.  It is supported as an IETF process efficiency 
hack only when there is rock solid working group synchronicity with the 
authors.  Based on the nature and extent of the problems I'm seeing with 
these documents, that synchronicity is lacking.

In sum:  The reviews I am doing are noting many and serious problems. 
They need working group discussion, not back-room author filtering, with 
selective public comments by the authors.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 07:15:22 -0700

On 8/9/2016 6:52 AM, Peterson, Jon wrote:
> a heap of obstructionism or personal animus.

Jon,

You appear to be having a problem refraining from ad hominem 
distractions in your latest messages.

I will ask that you step rather more carefully and quite a bit more 
professionally.

d/

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 9 Aug 2016 14:55:04 +0000

I don't know how to start a working group discussion about "many and
serious problems." Like I said, my first response to your stir-passport
review covered what I considered to be its most significant issues, which
were largely about the fundamental architecture and the document
organization (that is, the modularity with other specifications).

I just read the whole thing again. The remainder of your comments are
overwhelmingly stylistic, editorial or philosophical. The many places
where you call out points like "insecure" vs. "unsecure" are stylistic in
nature. At one point you say as an aside, "FWIW, this isn't quibbling.  It
is an example of the difference between regular prose writing and direct,
specification language." You make a number of organizational points about
where information should appear in the document, like in 3.1 how "the
section starts with structure detail and ends with purpose. This should be
swapped." Pervasive comments like "what is a persona?" or "identity
string? What does this mean?" are philosophical or terminological in
nature. We see these sometimes as technical objections, like when you
question what "delta time" means. You point out places where more
citations to existing RFCs would be appropriate. You question why some
things are SHOULDs and not MUSTs.

Are comments like this useful and actionable? They are, as I said in my
initial response to your review. Should we implement fixes for most of
these points? We should, as I said. But are these non-trivial, blocking
issues that require working group discussion to resolve? I must be missing
something. I'll ask again. If below the line in your stir-passport review
there are specific non-trivial blocking issues that warrant the attention
of the working group, please identify what they are. I honestly don't know
what working group discussion you think needs to happen.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 12:26:55 -0700

On 8/9/2016 7:55 AM, Peterson, Jon wrote:
> overwhelmingly stylistic, editorial or philosophical.

Jon,

Let's start with a rather simple exercise.

My review of passport has more than 70 questions in it.  (I stopped 
counting after that, and I haven't counted the number in -4474bis, 
though it too is substantial.)  While indeed, some of those pertain only 
to stylistic points many/most do not.

So the simple exercise is to ask you to please respond publicly to the 
questions I ask in my reviews.

And yes, it's fine to skip the obviously minor stuff.  If I think you 
missed something important, there's a reasonable chance I'll note it...

If you find yourself wanting more of a challenge, look for the various 
places that I note that something claiming to be (or to refer to) a 
specification does not actually supply specification detail or that the 
specification is wrong (eg, doesn't work) and then respond publicly to 
the substance.

Thanks.

d/
-- 

   Dave Crocker

---

From: Richard Shockey <[email-masked]>
Date: Tue, 09 Aug 2016 16:02:20 -0400

Well let me take this opportunity to totally reject Dave’s comments and the implication that we have not followed proper IETF process and procedures.

To make myself clear.

One, I support the continuing last call on these documents. I believe that these documents and the underlying protocols described are “fit for purpose” and in fact provide a valuable solution the problems described in the charter.  In addition, it is manifestly self-evident that the underlying JWT based passport structure is a valuable tool to describe and validate other “claims” that may be relevant in the future.  Purportedly we develop tools around here and not single purpose constructs.  The 4474bis concept is a much more extensible and economically viable protocol than the other alternatives such as issuing a 509 for every TN on the planet. Not going to happen. The initial problem in SIP are claims surrounding E 164 caller ID.  That the authors envision validating claims using other real time communications naming constructs, like WEBRTC is all well and good and we certainly expect to see more documentation on that in the future.

Second. My issue with the documents, is overall text clarity and lack of implementable examples to enable the supplier community to establish commercially viable roadmaps based on the eventual requirements flowing out of the service provider community.  Where do you put the claims in the INVITE guys????  There are endless political policy issues that have to be resolved but they will not, nor will they ever be solved in the IETF.   If you hate Telephony SP’s fine, its really easy to demonize them.  Done all the time.  But to get this thing off the ground we have to start somewhere and that means the circle of trust has to begin with the circle of authority and the delegation model here in every know nation state is virtually the same. The authority over the numbering plan and the integrity of the numbering plan is a nation state issue.  

If these are your real concerns you are welcome to join some of us in DC, London, Ottawa and other pleasant HQ’s for NRA’s.  Write your congresscritter, MP whatever.  If you want to go see the FCC btw send me a private note. The staff on 12th street here in DC are very very nice people and are quite happy to take technically informed meetings.  I can even tell you how to file an ex parte record of the meeting etc. 

Third, Dave’s objections here are fundamental. He is rejecting the entire JWT construct in 4474bis that has been put forward.  It is almost inconceivable to me that at this late stage he is essentially asking us to issue a ‘full stop” and start over in favor of DKIM based construct or whatever.  That is unacceptable.  NO. NO WAY.  We have no ID or anything before us to compare the merits of a DKIM approach to the one the consensus of the WG has chosen to adopt.  Spitballs from the peanut gallery do not count.  Write a draft Dave.  

Now I’ll let you return to your regularly scheduled programming. 

On 8/9/16, 10:12 AM, "stir on behalf of Dave Crocker" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    d/
    
    -- 
    
       Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 13:16:42 -0700

> Well let me take this opportunity to totally reject Dave’s comments and the implication that we have not followed proper IETF process and procedures.

Forgive me, but I did not intend -- and believe I did not assert -- any 
such implication of prior process problems.  To the extent that any such 
implications seemed apparent, I apologize for the confusion.

My concern was/is about the way my comments would be handled, wanting to 
make sure that what should be discussed openly would be.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 13:23:04 -0700

On 8/9/2016 1:02 PM, Richard Shockey wrote:
> Third, Dave’s objections here are fundamental. He is rejecting the
> entire JWT construct in 4474bis that has been put forward.  It is
> almost inconceivable to me that at this late stage he is essentially
> asking us to issue a ‘full stop” and start over in favor of DKIM
> based construct or whatever.

Rich,

Yes, late-stage concerns are always discomfiting.  But I'll again note 
that that I did not raise a concern about JWT/JSON in my Passport 
review.  And I raised concern about it in my 4474bis review only after 
trying to work through the actual use, within the context of these 
specifications.

What I found was considerable additional reading and technical 
complexity, with no immediate benefit for the task at hand.  So while 
the model is appealing, it actually seems to be a net negative, in this 
case.

I believe I also found serious errors, resulting from the complexity, 
but this is an example of one of those items in the review that need 
public response and discussion.  So I await clarifications that make 
clear that I misread the document...

d/

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 9 Aug 2016 21:21:06 +0000

While I hear your ask, I'm not sure I think giving individual answers to
the 70+ questions in your review are warranted. I'll be looking to the
chairs and the rest of the working group for guidance on this issue though
- if the prevailing sentiment is that I should answer them all, then I
will. 

In some cases, you pose questions related to a single incidental word
choice. "difference -> different?" is a question that doesn't require the
consideration of the entire working group. In a stir-passport passage
referring to "two new custom headers corresponding to the two parties" you
pose five questions: "corresponding? referring? describing? identifying?
addressing?" I think your point here isn't a question - or five questions
- at all, you're just unhappy with the use of the term "corresponding." As
it happens, I don't feel the usage of "corresponding" in this sentence is
a problem, but this is merely an editorial matter that I think can be
resolved without working group discussion.

Others of your questions are simply forms of mild emphasis that have been
disguised as questions for rhetorical effect. When we give an example of a
JWT header, for example, your review comment is "How is reader to know
what that long string means? Is the doc only for the cognoscenti? if so,
which cognoscenti?" I'm not sure the question of identifying the
cognoscenti for which this document was putatively written is something
that requires the attention of the working group. The first question, how
the reader is supposed to know what that long string means, is answered in
the next three sections of the document - one limitation of doing
line-by-line reviews like this in real time is that they tend to pose
questions that are answered in the document immediately afterward.

A lot of your questions are one-word "why?" questions which are surely
rhetorical.

Also, for those questions that do have some technical meat, we may have
already touched on them here on the list. Early on in the review, for
example, in response to the line in stir-passport reading "Tokens are a
convenient way of encapsulating information with," you interrupt, "Why?
What are the alternatives? Why is this the starting point?" You are making
rhetorical points here, that in your opinion using tokens for this purpose
has not been sufficiently motivated. We've talked about that quite a bit
on the list following your review about why we chose to use a token.

As such, I feel like answering many of these question would just be
busywork that will not in fact lead to any new list discussions or working
group insights or changes to what will get sent over the wire. I don't
think I have any obligation in our consensus process to vet issues that I
don't think warrant the attention of the working group - though again, if
the chairs and/or the group on the whole feel differently about these
issues, I will go with the group on this.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 14:46:22 -0700

Jon,

> - if the prevailing sentiment is that I should answer them all, then I

The idea that authors would seek working group consensus about whether 
to respond in detail to a detailed review is outside of my IETF 
experience.  I'm astonished at the very idea of it.

> In some cases, you pose questions related to a single incidental word

That why I made a point of acknowledging that there were minor issues 
and that eliding them is fine. Similarly, conflating a series of 
question to formulate a single response is likely to be fine.

I'm not clear what the point of raising something I already accounted 
for is.

> what that long string means? Is the doc only for the cognoscenti? if so,

In fact item was raising a serious and basic question, and it's not 
about cognoscenti.

> A lot of your questions are one-word "why?" questions which are surely

Few if any of them were asked rhetorically.

> rhetorical points here, that in your opinion using tokens for this purpose

The document doesn't explain what it means by token.  Yet it simply 
asserts their authority.  No context.  No justification.  Not even any 
definition.

So again, this wasn't a rhetorical query.

> busywork

That's a profoundly dysfunctional assessment.

d/
-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 9 Aug 2016 22:01:22 +0000

>experience.  I'm astonished at the very idea of it.

It is not at all outside of my experience to ask a working group if it
thinks that a set of objections (cast as questions or no) merit further
consideration. 

I will stress again that, from my initial response to your stir-passport
review, I immediately agreed that you had made some helpful comments in
there and that we would implement fixes for those. I am not going back on
that at all. Obviously, the working group will have the opportunity to
review a draft containing those fixes. All that we're discussing now is
the amount and character of discussion that needs to occur before that
step can be taken. If people feel like there's more discussion needed
before the editors can proceed, then by all means, let's have it. If not,
I see no reason to delay.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 15:18:11 -0700

> thinks that a set of objections (cast as questions or no) merit further

That's not quite what you are doing, Jon.  You are, instead, asking 
whether they are worth /any/ explicit, public consideration.  Really, 
that's a process point of an entirely different color.

> review, I immediately agreed that you had made some helpful comments in

Yes you did.  So it's unfortunate that that fact is entirely irrelevant 
to the current discussion, since it has nothing to do with the question 
of have /any/ detailed public response to details of a review.

d/

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 9 Aug 2016 22:35:53 +0000

Your comments went out to this public list, and the process of asking the
working group here whether or not people want further discussion is,
inescapably, public consideration. If you want to encourage discussion of
particular points that you think are vital for the working group to
consider, I would ask, yet again, that you identify what those points are
and discuss them. If the group agrees that more consideration is needed,
it will become clear pretty quickly, I imagine.

Jon Peterson
Neustar, Inc.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 09 Aug 2016 18:33:28 -0400

Apology accepted.  

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

On 8/9/16, 4:16 PM, "stir on behalf of Dave Crocker" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    d/
    
    -- 
    
       Dave Crocker

---

From: Richard Shockey <[email-masked]>
Date: Tue, 09 Aug 2016 18:46:43 -0400

Do you or do you not want a full stop?   Are you willing to go to the IESG and say these documents have not received full WG review? 

Put up or …

    

    d/
    
    -- 
    
       Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 13 Aug 2016 07:40:24 +0000

I finally had a chance to go through these comments, and I did want to
provide a few responses on Dave's review of rfc4474bis here.

>specifications are confusing and incomplete.  It is quite far from being

Having looked through Dave's specific concerns, I don't think he makes his
case for this criticism.

>be 'header field'.  My sense is that quite a bit of terminology is used

I think the use of terminology in the specification has proper background
and citations. Certainly Dave is correct that the text is pretty lax with
"header" vs. "header field" vs. "header field value," no denying that. If
people think this is a big deal, I will fix it. But the suggestion that
because this is true, terminology is loosely used to a point where it
would hamper implementation, that I think his comments don't really
substantiate.

>together.  In fact is appears that the document itself gets confused on

I'm not sure what an "integrative architectural description" would entail,
but there are a number of sections that provide overviews of operations
and related examples of how the architectural piece come together. I don't
think anything in the review comments genuinely substantiates that the
document itself is confused about its own architecture.

>can tell, the algorithms often are incomplete, but serious analysis is

Algorithms are offered in steps with normative language, if that's what
you mean by "prose form". RFCs are typically composed of prose. The review
does reveal some very striking views about specmanship and algorithms in
particular which are foreign to my experience in the IETF.

>be done after these specifications are published.

We do expect basic SIP literacy, and a willingness to follow references
and read external specifications and sections that are cited. Readers that
are unwilling to do this will probably find a lot of things confusing in
there.

>a number of semantic deficiencies in the text.

You did catch some good typos, and I caught a few more following your
notes through the text. I'm not sure that yielded the semantic
difficulties you speculate about here though.

>choices, not more.  Common, mandatory canonicalization is an example.

Common, mandatory canonicalization of telephone numbers is unfortunately
only slightly more reliable than common, mandatory normalization of
internationalized domain names. At least it's just numbers. The algorithm
we have is good enough to cover the common operational case, and where it
fails, hopefully "canon" will help to close the gap.

>specification completeness for the service.

Well, it does reference a standard for the specification of credentials:
stir-certs. I agree it would be a showstopper if we didn't have the
stir-certs work.

>does this ensure interoperability between two participants who have not

There is in practice only one at the moment. I'm content to worry about
interop problems when we have another one.

>administrative authorities, whereas telephone numbers do not...

I'd say that, by design, rfc4474bis is pretty tightly confined to
specifying the SIP over-the-wire protocol behavior. It takes a lot of spec
just to do that. 

And your praise of DKIM as a model is once again noted. I would respond
again that we are unlikely to abandon our years of work on this mechanism
and switch to DKIM at this point, no matter how many comments you place in
our path.

>keys is going to have no operational history of reliability, safety or

HTTP has none of those qualities, apparently.

>to be notably simpler and clearer.

I think enough of the concepts and protocol mechanisms of the original are
retained to warrant keeping this as a bis.

>picture, before diving into the detail of those to-be-integrated pieces.

Dave does make a number of organizational suggestions about the spec. The
spec has an overview, a design summary, before it gets down to specifying
things. The virtue of the "integrative" approach he describes is however
unclear to me. I think whether you define the auth service behavior first
or define the header syntax first, one of those sections is going to end
up pointing to the other. There wasn't much in his reorg suggestions that
seemed to me like a substantial improvement.

Overall, there are a handful of changes (beyond the typos, which again are
appreciated) I'd make based on the substance of Dave's review. Some of the
suggestions to rename sections seem harmless to me. Like some other people
who come to mind, he would like to see some more precise specification and
examples of how you break off the signature from JWT. He pointed out that
we really don't have any motivation for including multiple Identity
headers in there, and we probably do need an indication of what future
work might use that feature.

In terms of topics for discussion that might warrant the attention of the
working group, he did suggest we need to be sure we think the scope of the
signature is correct, and that we have enough confidence that
intermediaries won't break it, and that when it is broken, the verifier
behavior makes sense. I think we've focused a lot of attention on those
questions, but I'm happy to talk more about that if people think there's
room for improvement.

Also, he suggests that we might need a better pointer than RFC3986 Section
6.2.2 for URI normalization procedures. If anyone (including Dave!) knows
of one, I'd be happy to cite it instead.

Otherwise, I think we've got this covered. Anyone who's interested in
further details can see the attached.

Jon Peterson
Neustar, Inc.

---

From: Mary Barnes <[email-masked]>
Date: Wed, 17 Aug 2016 14:03:34 -0500

Jon,

Thanks for responding to Dave's comments - I found that quite helpful.  I
have some comments/responses below [MB].  As a caveat to my responses, I
did not read all the details in Dave's review.

Regards,
Mary.

> would hamper implementation, that I think his comments don't really

[MB] As pendantic as it might seem, in my experience, the expectation is
that we are precise with terminology in the specs, so that qualifying
'header' as 'header field' and 'parameter' as 'header field parameter' is a
reasonable expectation. I've had to do that with the RFCs that I've
authored and in re-reading this document recently, I think it adds to the
readability/understanding in particular since the ABNF comes later. [/MB]

> are unwilling to do this will probably find a lot of things confusing in
[MB]  I think the challenge is that 'basic SIP literacy' isn't such a basic
thing anymore and it does require *a lot* of background to parse this
document, but I don't know a way around that. [/MB]

> retained to warrant keeping this as a bis.

[MB] I'm not sure on this one, in particular given that it deprecates the
header fields defined in RFC 4474 (per section 8).  And, unlike other -bis
specs there is no summary section in this document of the differences
between the two.  Also, currently this draft doesn't indicate what impact
it has on 4474 in the header page. There is the sentence at the end of
section 1 stating that this document "revises RFC 4474" but that's not
particularly meaningful. Given that when we produced RFC 7044, we obsoleted
RFC 4244 despite RFC 7044 being backwards compatible with RFC 4244, I
really think that this draft should be documented as obsoleting RFC 4474.
[/MB]

> seemed to me like a substantial improvement.
[MB] As another RFC 4244 example, we did find that moving the syntax early
in the document in RFC 7044 made it more readable.  From a developer's
perspective, I think it's helpful to have the syntax in mind as one reads
all the details of the processing.[/MB]

> work might use that feature.
[MB] I would 3rd the need for examples.  That has been a usual practice for
other RFCs defining new SIP header fields (and header field parameters).
[/MB]

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 17 Aug 2016 21:48:34 +0000

Sorry.  Not responding to Mary’s excellent comments. I didn’t see Jon’s e-mail and don’t want to go look for it, so I’m replying to Jon’s e-mail that Mary was responding to.  (smiley emoticon)

In reading Mary’s remarks I saw that Jon said, “[Dave] pointed out that we really don't have any motivation for including multiple Identity headers in there, and we probably do need an indication of what future work might use that feature.”

It has occurred to me before that multiple signatures might be handy.  Intentionally and illegtimately authenticating spoofed calling numbers is possible.  A proxy which had information about an untrustworthy source might like to add a signature which in effect says, “you can trust the call came from the originator owning the certificate, but you cannot trust that the cert owner used it legitimately”.  It would be a way to preserve the originating authentication information which is useful, but deprecating it too.

I suppose there could be History-Info sorts of applications too.

Pierce

From: Mary Barnes [mailto:[email-masked]]
Sent: August 17, 2016 2:04 PM
To: Peterson, Jon <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Jon,

Thanks for responding to Dave's comments - I found that quite helpful.  I have some comments/responses below [MB].  As a caveat to my responses, I did not read all the details in Dave's review.

Regards,
Mary.

On Sat, Aug 13, 2016 at 2:40 AM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

[MB] As pendantic as it might seem, in my experience, the expectation is that we are precise with terminology in the specs, so that qualifying 'header' as 'header field' and 'parameter' as 'header field parameter' is a reasonable expectation. I've had to do that with the RFCs that I've authored and in re-reading this document recently, I think it adds to the readability/understanding in particular since the ABNF comes later. [/MB]

We do expect basic SIP literacy, and a willingness to follow references
and read external specifications and sections that are cited. Readers that
are unwilling to do this will probably find a lot of things confusing in
there.
[MB]  I think the challenge is that 'basic SIP literacy' isn't such a basic thing anymore and it does require *a lot* of background to parse this document, but I don't know a way around that. [/MB]

[MB] I'm not sure on this one, in particular given that it deprecates the header fields defined in RFC 4474 (per section 8).  And, unlike other -bis specs there is no summary section in this document of the differences between the two.  Also, currently this draft doesn't indicate what impact it has on 4474 in the header page. There is the sentence at the end of section 1 stating that this document "revises RFC 4474" but that's not particularly meaningful. Given that when we produced RFC 7044, we obsoleted RFC 4244 despite RFC 7044 being backwards compatible with RFC 4244, I really think that this draft should be documented as obsoleting RFC 4474. [/MB]

[MB] As another RFC 4244 example, we did find that moving the syntax early in the document in RFC 7044 made it more readable.  From a developer's perspective, I think it's helpful to have the syntax in mind as one reads all the details of the processing.[/MB]

[MB] I would 3rd the need for examples.  That has been a usual practice for other RFCs defining new SIP header fields (and header field parameters). [/MB]

Jon Peterson
Neustar, Inc.

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 18 Aug 2016 16:43:00 +0000

Hi Mary,

If people really feel like it needs to be fixed, I can fix it - but I do feel justified in pointing out that our track record with this in SIP documents isn't real strong. The original RFC4474 used "header" informally quite a bit. So does RFC4244, actually, if you scroll through that. So does the Replaces header spec. So I'm not sure we really do have much of an expectation about being precise with this. The reason why, I imagine, is because the common and casual way we use it isn't actually ambiguous - no one who sees the phrase "Date header" is confused about whether we mean a header or a header field.

But like I said, it isn't a huge deal to fix it - it's just that any pervasive edits like this can give rise to errors, and it's not clear that fixing this solves any real problem.

<snip>

There is a summary of changes in the document; it's Section 15 "Changes from RFC4474". And well, the bis doesn't deprecate both the headers as such, it deprecates one header field and changes the syntax of the other. But more importantly, it keeps all the guts: the concept of an authentication and verification service, all the response codes, all the associated SIP behavior. The only real semantic change is the scope of protection of the signature itself, which has been reduced overall, and then with respects to the identities in particular has been honed to deal with telephone numbers better. Obsoleting the Identity-Info header and moving it into an "info" parameter of the Identity header is a just a syntactic change. Although we created some architectural modularity around credentials, the stir-certs mechanism still has the same properties as certs did in the original architecture. Allowing the Identity header to appear multiple times just removes a limitation in the original spec that doesn't seem useful in retrospect (and the way Identity-Info was originally done didn't allow it) rather than a change to how the header is to be understood.

All that said, I do agree it probably should obsolete RFC4474, not merely update it. Or at least that's how I remember the process is supposed to work. I'll defer to chairs/Ads on this one.

There will be more examples!

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 18 Aug 2016 16:48:24 +0000

Oh, we've allowed for multiple Identity headers for some time - the problem is we don't really give any reason why we allow them or any sense of what it might mean to have more than one. We need to say at least something about that, though largely this is a matter of forward compatibility with some future use cases that we know are under consideration that we don't want to rule out.

Jon Peterson
Neustar, Inc.

From: "Gorman, Pierce A [CTO]" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 17, 2016 at 2:48 PM
To: Mary Barnes <[email-masked]<mailto:[email-masked]>>, Jon Peterson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Pierce

From: Mary Barnes [mailto:[email-masked]]
Sent: August 17, 2016 2:04 PM
To: Peterson, Jon <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Jon,

Regards,
Mary.

Jon Peterson
Neustar, Inc.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 18 Aug 2016 17:02:52 +0000

Agree.  There might be other ways to deal with multiple Identity headers, but a push/pop stack is what comes to mind.  I would want some way to tell which Identity header was applied first, second, et cetera.

Pierce

From: Peterson, Jon [mailto:[email-masked]]
Sent: August 18, 2016 11:48 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Jon Peterson
Neustar, Inc.

Sorry.  Not responding to Mary's excellent comments. I didn't see Jon's e-mail and don't want to go look for it, so I'm replying to Jon's e-mail that Mary was responding to.  (smiley emoticon)

In reading Mary's remarks I saw that Jon said, "[Dave] pointed out that we really don't have any motivation for including multiple Identity headers in there, and we probably do need an indication of what future work might use that feature."

It has occurred to me before that multiple signatures might be handy.  Intentionally and illegtimately authenticating spoofed calling numbers is possible.  A proxy which had information about an untrustworthy source might like to add a signature which in effect says, "you can trust the call came from the originator owning the certificate, but you cannot trust that the cert owner used it legitimately".  It would be a way to preserve the originating authentication information which is useful, but deprecating it too.

Pierce

Jon,

Regards,
Mary.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Aug 2016 10:05:48 -0700

On 8/18/2016 9:48 AM, Peterson, Jon wrote:
> Oh, we've allowed for multiple Identity headers for some time - the
> problem is we don't really give any reason why we allow them or any
> sense of what it might mean to have more than one. We need to say at
> least something about that, though largely this is a matter of forward
> compatibility with some future use cases that we know are under
> consideration that we don't want to rule out.

1. In the abstract, there could be different identifiers that are 
authenticated.  That's probably not supposed to be allowed for a SIP 
environment, but since there apparently can be different identifiers 
used as input to validation, perhaps it is allowed.

2. There can be different authorities used to create the authentication. 
This permits trust assessment of a combination of entities making 
validity assertions.

3. There can be different technical details to the signature.  Different 
canonicalizations, different crypto algorithms, different keys.  All of 
these might affect survival through transit and/or ability of the 
recipient to process.

d/
-- 

   Dave Crocker

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Aug 2016 10:44:52 -0700

Mary Barnes said:

"I'm not sure on this one, in particular given that it deprecates the
header fields defined in RFC 4474 (per section 8).  And, unlike other -bis
specs there is no summary section in this document of the differences
between the two.  Also, currently this draft doesn't indicate what impact
it has on 4474 in the header page. There is the sentence at the end of
section 1 stating that this document "revises RFC 4474" but that's not
particularly meaningful. Given that when we produced RFC 7044, we obsoleted
RFC 4244 despite RFC 7044 being backwards compatible with RFC 4244, I
really think that this draft should be documented as obsoleting RFC 4474."

[BA]  Agree that the document should include Obsoletes: 4474 in the
header.  The Abstract and Introduction could also set the context somewhat
better.

Section 15 is a bit terse and could probably be expanded. However, if the
context for RFC 4474bis is properly set, I don't think we need to go
overboard on that.

On Wed, Aug 17, 2016 at 12:03 PM, Mary Barnes <[email-masked]>
wrote:

> [MB]  I think the challenge is that 'basic SIP literacy' isn't such a
> basic thing anymore and it does require *a lot* of background to parse this
> [MB] I would 3rd the need for examples.  That has been a usual practice
> for other RFCs defining new SIP header fields (and header field
> parameters). [/MB]
>
>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 18 Aug 2016 17:51:24 +0000

The most common uses we envision look like 2 or 3: either cases where some
specialized authority signs for an identity, one who is not necessarily an
authority for the telephone number in question but will be trusted by
relying parties for some other reason; or cases where you are adding some
new field to the scope of protection, like say the display-name or some
non-SIP field. But yes, 1 could also be the case for some of the
interworking with WebRTC IdPs we've considered. For the purposes of this
spec, though, we just want some very high-level motivation.

Jon Peterson
Neustar, Inc.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 17:58:28 +0000

Hi,

>From my experience as GenART reviewer, I can say that usage of consistent terminology is something that the whole IETF suffers from. But, it's getting better :)

There are also cases where we DO use consistent terminology, but where people have a different understanding of what it means. "Codec" is a very good (and unfortunately very often occurring) example. So, while the authors, or even everyone in the WG, have a common understanding of what something means, we need to make sure others will too.

Regards,

Christer

From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: 18 August 2016 19:43
To: Mary Barnes <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Hi Mary,

<snip>

Jon Peterson
Neustar, Inc.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 18:19:11 +0000

>From my experience as GenART reviewer, I can say that usage of consistent >terminology is something that the whole IETF suffers from. But, it's getting better :)

The usage of inconsistent terminology, that is.

From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: 18 August 2016 19:43
To: Mary Barnes <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Hi Mary,

<snip>

Jon Peterson
Neustar, Inc.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 18 Aug 2016 16:15:16 -0500

Hi Jon,

More responses inline below [MB].

Mary.

On Thu, Aug 18, 2016 at 11:43 AM, Peterson, Jon <[email-masked]>
wrote:

> If people really feel like it needs to be fixed, I can fix it - but I do
> feel justified in pointing out that our track record with this in SIP
> documents isn't real strong. The original RFC4474 used "header" informally
> quite a bit. So does RFC4244, actually, if you scroll through that. So does
> the Replaces header spec. So I'm not sure we really do have much of an
> expectation about being precise with this. The reason why, I imagine, is
> because the common and casual way we use it isn't actually ambiguous - no
> one who sees the phrase "Date header" is confused about whether we mean a
> header or a header field.
>
[MB] I don't disagree in general and specifically about RFC 4244, but we
went to a fair amount of effort for 4244bis (i.e., RFC 7044) to be more
precise and I do believe it improves readability and makes it more
understandable on a first read, in particular for folks that haven't been
involved in SIP standardization for 20 years.   Also, given the ordering of
the sections (i.e., ABNF towards the end), I find it really helps for
"canon" and "ppt" to be qualified as "header field parameters".   [/MB]

>
> But like I said, it isn't a huge deal to fix it - it's just that any
> pervasive edits like this can give rise to errors, and it's not clear that
> fixing this solves any real problem.
>
[MB] I don't disagree that there is a risk of introducing errors, but I
think, while tedious, this change is fairly straightforward in doing a find
and replaces (I personally usually don't do global changes as I'd rather
eyeball things to avoid the possibility of introducing the sorts of errors
you note).

Also, per Christer's later comment, I do think making the spec more
readable will be helpful for the gen-art reviewer.  My personal preference
is to fix things in the WG as it avoids others raising similar issues down
the road.  Of course, as you note, if I'm the only one that has this
concern, then fine. [/MB]

> There is a summary of changes in the document; it's Section 15 "Changes
> from RFC4474". And well, the bis doesn't deprecate both the headers as
> such, it deprecates one header field and changes the syntax of the other.
> But more importantly, it keeps all the guts: the concept of an
> authentication and verification service, all the response codes, all the
> associated SIP behavior. The only real semantic change is the scope of
> protection of the signature itself, which has been reduced overall, and
> then with respects to the identities in particular has been honed to deal
> with telephone numbers better. Obsoleting the Identity-Info header and
> moving it into an "info" parameter of the Identity header is a just a
> syntactic change. Although we created some architectural modularity around
> credentials, the stir-certs mechanism still has the same properties as
> certs did in the original architecture. Allowing the Identity header to
> appear multiple times just removes a limitation in the original spec that
> doesn't seem useful in retrospect (and the way Identity-Info was originally
> done didn't allow it) rather than a change to how the header is to be
> understood.
>
> All that said, I do agree it probably should obsolete RFC4474, not merely
> update it. Or at least that's how I remember the process is supposed to
> work. I'll defer to chairs/Ads on this one.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 11:49:39 -0400

> these might affect survival through transit and/or ability of the

I think all of these are plausible and valid possibilities.

What this means is that any *prioritization* of these needs to be a 
decision made by the validator (perhaps differently for different 
validators in the same call), and not by the signers.

	Thanks,
	Paul

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Aug 2016 08:55:00 -0700

> validators in the same call), and not by the signers.

Paul,

As you have phrased it, this seems likely to produce non-interoperability.

Some -- and maybe all -- of the details concerning the basic mechanics 
and semantics of multiple signatures need to be specified for consonant 
behavior between signers and validators.  Otherwise, the signer won't 
know how the validator will interpret the signatures.  And the validator 
won't know what the signer(s) meant.

(This is, of course, separate from any policies the receiving side might 
choose to have for the /use/ of the results of that interpretation.)

d/

-- 

   Dave Crocker

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 12:13:06 -0400

On 8/18/16 2:19 PM, Christer Holmberg wrote:
>
>
>>From my experience as GenART reviewer, I can say that usage of consistent >terminology is something that the whole IETF suffers from. But, it’s getting better :)
>

+1

For the specific case of header vs. header field vs. header field 
parameter, these have long been used in a sloppy way. (And I admit to 
being a frequent offender.)

Also note that while "header field" is used widely in 3261 it is never 
defined. By context it is clear that it means the same as the abnf rule 
"message-header".

Nor is there any definition of "header" in an unqualified form in 3261, 
nor (afaik) any use of that.

In informal conversation it is common to use "header" in lieu of 
"message-header"/"header field", and I would be shocked if its use ever 
causes any confusion.

I am in favor of cleaning up usage for consistency, using "header field" 
or "header field parameter" when appropriate. But I consider this an 
editorial issue, not a semantic issue.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 12:17:19 -0400

> choose to have for the /use/ of the results of that interpretation.)

The latter is what I was talking about.

One validator may trust a particular signer, while another has that 
signer on a blacklist. I think this is unavoidable, and in fact can be 
considered a *feature*.

	Thanks,
	Paul

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Aug 2016 14:54:29 -0700

Folks,

This note responds to Jon's responses to my review.  (I'll be responding 
to Russ's request separately.)

Correlating Jon's responses with the actual review (and therefore also 
to the full specification), to get a more complete context, proved to be 
an excessive burden, as well as making it essentially impossible to 
determine what was skipped.

So I've integrated:

      > Jon's responses into

      >> my original review note,

to eliminate that burden.  I'll apologize now, for the inevitable 
miscorrelations that are sure to have occurred.  Also, I'd advised Jon 
that skipping the small stuff would be fine, but he seems not to have 
done that, except sometimes...

(In a meager effort to abbreviate things, however slightly, I've deleted 
text of Jon's, at the beginning of each his response entries, meant to 
provide context for the response, since the context will now be readily 
evident.  I realize that readers will miss his colorful annotations used 
to introduce my comments, with really spiffy choices like: warily asks, 
squints, alleges, interjects with sound and fury, exclaims, denounces, 
condemnation, confesses, defiant, blurt out, gamely notes, and well gosh 
so many more clever choices.  But my favorite was "interjects with 
bafflement"; that was really creative.)

I've put "{{ No response from Jon. }}" as needed.  Again, for the minor 
stuff, in a normal review discussion, I wouldn't worry about such 
omissions. Alas, given the realities of this particular exchange, it 
seems worth marking things explicitly for the record.

I'm also sorry that I think it necessary to include all of the original 
material.  Again, in a normal exchange I'd elide as much as possible, 
but am afraid it would be risky here.

> On 8/8/2016 8:46 PM, Dave Crocker wrote:

{{ No response from Jon. }}

 > The very first interjection in the line-by-line review rejects the
 > assertion in the Abstract that the security mechanisms of SIP are
 > "inadequate for cryptographically assuring the identity of end
 > users," instead arguing that we should substitute "adequately" for
 > "cryptographically". This would however result in text that reads
 > "inadequate for adequately assuring the identity of end users." I
 > think "inadequate for adequately" is a poor change. This is a pretty
 > good indication of the major limitation of the review overall - these
 > line-by-line comments often consider only one atom of the spec in
 > isolation from its surrounding context, and thus pose difficulties
 > that don't actually exist and propose remedies that do not fit very
 > well into local surroundings or overall plan.

One would have thought that the summary comments, at the beginning, 
would have sufficiently served in terms of the larger picture.

And while yes, I didn't catch the redundant vocabulary, you seem to have 
missed my point entirely.  So I'll say it more fully:

         Overview text, for anything that is not defining new 
cryptography, but which starts by citing cryptography, is usually 
failing to focus on what is primary:  necessary goals and functionality, 
which are the why and what, and is instead being distracted by the 
underlying mechanics, which are the how.  In this case, that means it 
should not be citing crypto but should, for example, authentication.

Cryptography and the use of cryptography are not a primary goal and so 
the summary text should instead focus on the primary goals.

>> issue, with language like "especially across trust boundaries" or somesuch.

{{ No response from Jon. }}

 >      At a high level, I
 > don't object to the existence of a terminology section, but as, to my
 > knowledge, only three terms defined here - identity, auth service and
 > verification service - I kind of think it's overkill. Also, all three
 > of those terms in their current sense carry over from RFC4474, which
 > made it to RFC without a terminology section.

I don't understand the rationale behind citing a failed RFC as 
precedent.  In any event my point was simple:  When there are terms of 
art used in a document, they should be defined.  A terminology section 
is a common way of doing that, especially since the document already has 
one.  The benefits are to first to introduce the reader to the terms, 
before they are needed, and second to make referencing back to the 
definition easy.  As for whether there are only 3 terms in the document 
that need to be explicitly defined, I didn't do an audit, but I believe 
the actual number is significantly higher.

 >     [I]t belongs where it does because this is an
 > update to a prior RFC, and the relationship to that RFC should be
 > described up front. It also contains some important info about the
 > objectives of the revised mechanism, including reducing signature
 > breakage.

A specification is not an historical narrative.  It's job is to specify.

To the extent that historical narrative is necessary -- which it is not, 
in this case, given the lack of any installed base that cares about the 
history -- that should go into a separate section that can be ignored by 
developers.  When historical narrative does have relevance, it needs to 
be quite brief; when it isn't, the text is a distraction.

 >      While I
 > don't think this could realistically give rise to any confusion that
 > would impact implementers, or improve the readability of the spec, it
 > isn't a change I'd rule out. I don't see any great urgency to do it,
 > either.

Yeah.  Clearer organization, designed to facilitate initial reading and 
later consultation, probably isn't all that helpful.

>> add:  Hence the foundation to accurate authorization is valid

{{ No response from Jon. }}

>>           ...enables an authentication capability for protecting against...

{{ No response from Jon. }}

 >    As described in this
 > specification, an authentication will not do that.

On reflection, the more interesting issue is reference to an 
'architecture' which is not defined (or depicted) in the document...

Worse, from various postings over the last few weeks, it's clear that 
different people have a different sense of what the purported 
architecture is.

>> operator?  the term is ambiguous.

{{ No response from Jon. }}

>> worth breaking this sentence into two, for better clarity.

{{ No response from Jon. }}

>>>    however.  Authority over telephone numbers does not correspond

{{ No response from Jon. }}

 >       But
 > actually the text says:
 > service for that domain can issue them an identity in that
 > namespace, such as [email-masked]. Alice may then send REGISTER
 > requests to example.com that make her user agents eligible to receive
 > requests for sip:[email-masked].
 > > ... so it says sip:alice@, not merely alice@, and in fact a search
 > will show that exact string "SIP URI" does appear in Section 3.

The alice@ string was a shorthand.

Actually Section 1.  *This* is Section 3.

 >   The review here does not like the
 > presentation of this material in a section called "Background." It is
 > hard to see how much sooner in the specification statements can be
 > made than here.

A statement of the purpose of a document should come sooner than Section 3.

 >      This is
 > a section on background, it is does not detail the protocol's
 > operations. This review is very critical of forward references, and
 > yet equally critical of any section that lacks them. Information has
 > to be communicated in some order. Giving a big picture up front
 > without such details is helpful.

Alas, talking about Passport and JSON is not 'background'.  "Background" 
normally means setting the stage about problems, needs, and maybe prior 
work.  Yet this references text is about the *technical substance of 
this document*.  That's 'fore'ground.

 >      No, the "authentication service" as
 > described here behaves differently, and does not appear on the
 > verifying side. A diagram isn't out of the question, but the
 > difficulty is that the authentication service is a logical role that
 > might be played by elements in different components of a call flow,
 > so it would always be just an example instantiation rather than a
 > complete picture.

The term is used as if it is a term of art.  But no definition is given 
here or later and, as you note, it has no precise meaning.  It could be 
this or that, here or there.

 >      This is the first of many places where the
 > review mentions this. There's another in 5.1 ("header? or header
 > field?"), some in 5.2 ("headers? header fields?" and a few hints of
 > "header [field"), at the beginning of Section 8 ("header *field*")
 > and so on. To be clear, the review is absolutely correct that there
 > is a distinction between a header, a header field, and a header field
 > value, and that the text in rfc4474bis handles that distinction
 > pretty loosely. It is full of constructions like the following (taken
 > from 5.1):
 > > In one case there, it uses the full construction "Date header field",
 > and then in literally the next sentence, it casually uses "Date
 > header" instead. From a quick glance at the usage of "header" vs.
 > "header field value" in rfc4474bis, it looks like "header" appears
 > around 240 times, and "header field" only a few more than 70. Surely
 > most of those usages of "header" should actually be "header field",
 > as in the quote from 5.1 above. Probably many more should be "header
 > field value" (which appears only a dozen times). However... SIP has
 > never been real good about this. Oh, I remember during RFC3261 how
 > diligent we were in trying to keep these straight. But if you look at
 > subsequent header specifications for SIP, like say Replaces (RFC3891)
 > or History-Info (RFC4244), we never really locked this down. The
 > numbers of "header" vs. "header field" vs. "header field value" for
 > the original RFC4474 are pretty similar to what we see in rfc4474bis.
 > I think the reason why we continue to use it pretty casually is,
 > well, because as that quote above from 5.1 illustrates, there isn't
 > any damaging ambiguity about this. The second sentence really is
 > talking about the "header field value", as it is not the "header
 > field" that is "accurate" or not. I suspect the reason why we SIP
 > folks have been lax about this is because the construction "Date
 > header" in sentences like the above is not actually unclear in any
 > meaningful way, it is perfectly obvious what it means. All that said,
 > it isn't a huge amount of work to be precise about this - if anyone
 > would like to make the case that there's actually a practical problem
 > here rather than a merely pedantic exercise involved. The casual use
 > of "header" certainly hasn't prevented the publication of many
 > previous SIP header specification RFCs.

I'm not sure what the point of a lengthy history about other 
inconsistent uses of the terms is, unless they are supposed to somehow 
make inconsistent use acceptable here.  They don't.

Really, I was making only the simplest of points:  These terms have 
definition and this document is a specification.  It should define (or 
cite definitions of terms of art and it should use them carefully and 
correctly.

 >      I think it is pretty
 > clear from a casual glance at the RFC series that statements about
 > directions for future work are common in RFCs, and that there is no
 > bar against them.

Some RFCs are written well; some are not.  This appears to take the view 
that the very large body of problematic RFC content serves as precedent 
to allow the continued writing of bad RFCs.

Forgive me for taking the view that the goal should be writing RFCs well 
and noting that RFCs that are clear about the boundaries of the spec -- 
including explicitly noting items that are outside of scope -- tend to 
be the better sort of writing, as do RFCs that refrain from predicting 
the future, especially since they are almost always wrong.

>      As far as odd thoughts go, that's not far from
> how we see it. We imagine there will be hopefully seamless gatewaying
> to a lot of non-SIP applications. Cullen's draft about WebRTC
> gatewaying is a good place to look at what some of the practical
> challenges are to getting this to work.

Hence my point that JSON/JWT aren't native to this work.  While I'm a 
fan of a core, canonical representation when there is a gatewaying 
model, the nature of gatewaying that is interesting is semantic mapping 
and the fact of the matter is that anything other than trivial 
encoding-translation gatewaying loses information... Always.

(My graduate work was on email gatewaying, which was popular and 
necessary back then, so this technical aspects of gatewaying, as a 
special type of processing, is particularly significant topic to me.)

(BTW, all I found was draft-ietf-rtcweb-gateways-02, which isn't by Cullen.)

 >    Well, what it means is
 > explained if you don't take this phrase in isolation and pretend like
 > it is something with no context. The prior sentence begins by stating
 > that the authentication service function can exist at either a user
 > agent or a proxy server. One of those is an endpoint and one is an
 > intermediary. For something to be "end-to-end", it will extend from
 > endpoint to endpoint. As the authentication service does signing, it
 > requires credentials to perform the signature. In order for an end
 > user's endpoint to act as an authentication service, the end user
 > thus needs to be able to acquire credentials. The rest of this
 > paragraph is about why that isn't so easy. I don't think this is
 > either incorrect or particularly hard to follow from the text that is
 > already there.

That's the problem with having text that makes a very broad assertions 
without explaining them.  There is a rather substantial body of 
experience that says that individual end-users tend to be really awful 
at doing all the stuff that serves as the basis for the simplistic 
assertion here.

If the draft had said something more like "To maximize end-to-end 
security, it is obviously preferable for end-systems to acquire their 
own credentials", the problematic human factor would be removed and the 
valid technical point would remain.

 >       The
 > "overview of operation" here follows the section  of the same name,
 > which also happens to be section 4, in RFC3261. Okay, the name of the
 > section there is singular and not plural - but it is also basically a
 > concrete example.
 > > * That much said, I'd be willing to change the "Background" section
 > to "Overview" and move the "Overview of Operations" section into an
 > "example" subsection of "Overview", if that helps. Again, I don't
 > think it'll help much, if at all, but it's easy to do.

 >      The use of TLS to
 > protect the first hop from the user agent to an intermediary-based
 > authentication service has security properties that are discussed
 > later in the document, in particular in Section 12.4. But for the
 > purposes of this overview here, it is merely exemplary.

I think that the problem is with the entire approach to the section. The 
title of the section does not match the content.  The content is merely 
a specific example.  Examples preclude alternatives.  In this case it 
appears that the example also extends beyond the scope of the 
specification itself.  So, for example, TLS comes in as a tidbit of 
detail, about a system component that is not covered in detail by the 
specification.

Reference to TLS is appropriate for an overall system description that 
covers all of the pieces at all of the layers.  Within a specification 
about a SIP Invitation Signing and Verifying protocol, it is a layer 
violation.

>> operationally relevant here?

{{ No response from Jon. }}

>> say what and we won't say where to find out.

{{ No response from Jon. }}

 >      Well, I disagree. Having a non-normative overview of
 > how the mechanism works is valuable precisely because it is not
 > muddled by the motivation or the specification.

Perhaps the import of 'vague' and 'neither motivated nor explained' 
wasn't clear.

I'll try harder:  Text that is meant to explain things should explain 
things.  Telling people about an action that is not explained introduces 
the alternative but gives the reader no understanding about it.  It does 
not even tell them what the *range* of equivalent alternatives is.

What's missing is a separate description of this service, independent of 
the specifications for its technical details.  Hence the text here is 
conflating document goals and it's not being clear about that.

 >      This is a comment the reviewer has raised
 > before, will raise again below in the comments on 6.2. The short
 > answer is that there is no security hole, but a long response will
 > wait for 6.2 (if we can use a forward reference here). This is just a
 > section saying how the mechanism operates, not why the mechanism
 > operates the way it does.

>> might be some, both it won't be true that */all/ incoming requests are

 >      The actual policies that SIP entities apply to requests
 > in the presence or absence of the Identity header are outside the
 > scope of this specification, as is clearly stated at the end of 5.2.
 > The short answer is that this is an over-the-wire protocol spec, and
 > that as such, it is already complex enough without dipping into those
 > matters. But again, Section 4 probably wouldn't be the right place to
 > explore that question anyway.

That response suggests a serious lack of attention to well-established 
operational issues for this topic:  The handling of a missing signature 
and the handling of a broken signature are an essential part of a 
signature service, especially when the service is being added to an 
already-running service.

The realities of call request transit are going to have serious 
complexities for a long time, possibly forever.  Transit complexities 
are essentially certain to sometimes break otherwise-legitimate signatures.

Their semantics for handling need to be standardized, lest the 
inevitable variations of 'local policy' undermine the the efficacy of 
the overall service.

 >      We are
 > certain that, with some exceptions detailed in the document, we want
 > to treat the breaking of the signature in transit as a security
 > violation, regardless of why it happens.

*That's a mistake. If the infrastructure will sometimes break the 
signature, then penalizing the signer for actions not under their 
control will be problematic.  That's why DKIM explicitly mandates 
treating a broken signature exactly the same an absent signature.*

 >           Circumstances in which the
 > signature might be broken are discussed throughout the specification.

Scattering this essential topic all over a document does not facilitate 
getting careful, focused consideration of it.  Yet it is a discrete 
topic, entirely amenable to that focused attention.

 > In fact, the mention of this in the last paragraph of Section 1 is
 > one of the reasons why that text needs to stay in the specification.
 > This entire effort, as the STIR problem statement (RFC7340) says, was
 > largely motivated by trying to minimize signature breakage. It is
 > nice that the overview of operations at least inspires these
 > questions, which are the right sorts of questions to be asking about
 > a mechanism like this. Suffice it to say that we've thought about the
 > past three questions a lot over the years - these aren't exactly new
 > issues being raised.

No they aren't.  DKIM wrestled with them extensively roughly 10 years 
ago.  To the extent that STIR came up with different answers, it is not 
possible to see that it did or why, but it should be.

 >      A similar comment is made about the
 > first sentence in 5.2. I do not believe it is a problem for sections
 > of a specification to begin with an introductory sentence that queues
 > up the topic about to be discussed. I comment more about this as a
 > document organization matter, as that is how it is raised in 5.2 - as
 > a question of redundancy.

A continuing issue that I found significant enough to count as 
problematic is extreme redundancy and verbosity throughout the document.

Overall, the document seems to have been written with the view that more 
words are always better, rather than that the right *balance* of words 
is best and that excessive text serves more as a distraction than as 
clarification.  That's why I gave in to using the unpleasant word 
'bloated' when commenting on the set of documents.

The fact that IETF documents are free to include background and 
explanations is one of the things that make them so much better than the 
stilted over-structured documents done is some other SDOs, but this does 
not mean that constantly tossing in extended text is helpful.

 >       The idea that there are
 > abstract "roles" which are instantiated by entities in a SIP
 > architecture for the purposes of even a single transaction is a core
 > SIP concept (see the UAC or UAS roles, or RFC3261 10.1 on the
 > abstract "location service"), and is foundational to how the
 > mechanism in this document is to be understood. This specification is
 > only defining an "architecture" in so far as it defines the
 > authentication and verification service roles.

This appears to be a very basic disagreement about a very basic issue!

*In point of fact, these specifications are attempting to define an 
authentication service overlay for SIP.  That is, STIR is an additional 
layer of architecture ABOVE SIP. *

An example of a comparable overlay is shown in Figure 1:

          DKIM Service Overview
          https://tools.ietf.org/html/rfc5585

DKIM is on top of RFC 5322, not part of it, just as STIR is on top of 
SIP and is not part of it.

This really is quite an important architectural point, IMO.

 > No, an authentication service may have multiple credentials
 > associated with different names, where each credential has an
 > associated public and private key. Review proposes the wording "The
 > authentication service possesses the private..." but this is
 > rejected, because that loses the sense that there may be multiple
 > private keys due to having authority over multiple names.

I'm not sure what "there may be multiple private keys due to having 
authority over multiple names" means exactly, but it probably doesn't 
matter for the immediate issue.

A STIR-signed request comes in.  The host doing the evaluation needs to 
find the key.  They need a simple, efficient, reliable and secure means 
of locating that key.  They are not going to search among multiple 
credentials, so in this context, it doesn't matter that there might be 
multiple.  At the time of the lookup, they need to get to the one, 
correct credential needed at that time.

Mostly, this discussion of credentials and keys is vague and confusing, 
but it needs to be extremely clear.

 >     The scope of the credential is over the domain or
 > telephone number, and the credential could be used outside the SIP
 > context - there's no sense in which the credential is specific to the
 > identity appearing in a From header field. The value of this proposed
 > edit is thus very dubious.

First, text that has to constantly cite an 'or' condition, as above, is 
text that has not properly factored issues and references. As an 
example, the phone-number/domain-name distinction should be dealt with 
in some isolated sections and there should be a common name for the 
obtained value in the rest of the document.  I keep using 'caller-id' 
because various folk thought it a workable choice, but I don't care what 
specific term is used.

A common way to do this kind of abstracting of a set of technical 
choices is to define some ABNF that lists the alternatives and use the 
rulename for that ABNF in the rest of the document.  In other cases what 
suffices is prose that defines a term, where the definition is the set 
of alternatives.

The change in wording I was suggesting was trying to get to a single 
common term.  I'm also fine if 'From' value is not the correct answer. 
But the document is constantly going back to underlying alternatives 
throughout rather than building things up into integrative constructs 
and labels for them.

As for the explanation about credentials, I did not see anything in any 
of the three documents that specified/explained any of this well enough 
to provide or anticipate the above response.

 > The review here refers to whether the header syntax (Section 8)
 > should go before authentication service behavior (Section 5.1). There
 > is no free lunch here; neither belongs before the other, one will
 > have to refer to the other. We can't do everything at one time.
 > Complaints like this are easy to lodge, but that doesn't make them
 > persuasive.

As I tried to explain:

*The current approach places an extra burden on the reader.  They are 
constantly presented with important terms and details that they do not 
yet understand. This forces them to interrupt their current reading, 
mark their place, and go search for the underlying detail, if they want 
to understand the current text.  In contrast, a bottom-up model for such 
presentation of information ensures that the user can read in a smooth 
sequence, without the interruption.*

The issue is not about the need for references, but about the reading 
process.

 >  Identity is a
 > fundamental concept in this document, there is no need to refresh it
 > here.

Apparently the word 'referent' was not clear.  Sorry.  I meant that for 
the next use of identity (just below,) the 'that' isn't a clear 
reference to me.  I was commenting on ambiguous writing, not the meaning 
of the term identity.

 > This text in the introductory paragraph states, as a prerequiste for
 > operations, "Intermediaries that instantiate this role MUST be
 > that identity." The text in step 2 states that during operations,
 > "The authentication service MUST then determine whether or not the
 > the identity field." The distinction here is between stating a
 > prerequiste for any activity and then mandating performing the
 > activity as a component of normative messaging processing. It is not
 > redundant.

 >      No, the purpose of statements like this in
 > specifications is to say "hey, we thought of an idea that might be
 > useful someday, and while we didn't want to spec it now, we did want
 > to capture it and try to structure the mechanism in a way that
 > wouldn't preclude it, in case somebody feels like fleshing this out
 > sometime." The contention that statements like this are abnormal in
 > IETF specifications would not withstand even casual scrutiny.

Fantasy is fun.  Discussing enhancements is fun.  But it isn't 
specification.  And, again, it is rarely correct, especially when the 
fantasy asserts a future statistic, like 'commonly'.

(Again, the fact that some RFCs indulge in poor practices ought not to 
serve as justification for doing more of the same. Precedence is good 
for something that is useful, not for something that is problematic)

So move it out of the specification, into a carefully marked section or 
document that makes clear it is romping through fields of possibility 
that might or might not have anything to do with what actually will 
happen.  Placed in the middle of technical specification, it serves as 
distraction for the developer.

 >      I don't think there is any harm in
 > beginning a paragraph that describes the steps taken to add an
 > Identity header to a request with a topic sentence that states what
 > an authentication service does at a high level.

There is harm.  It bloats the document.  It bores the reader.  It 
invites opportunities for making errors by virtue of creating text that 
might vary from its sibling (parent?) text, thereby creating conflicting 
content.

It also makes revision more difficult, when every occurrence of 
something needs to be tracked down and modified. (By way of example, the 
reply to my review was done as a note entirely separated from my inline 
review, but included text at the beginning of each response that was 
intended to set context, usually by quoting my text and/or the draft's 
text. Periodically, those quotations had errors...

>> And, by the way, what header field is that?

{{ No response from Jon. }}

 >    This is just
 > introductory material that sets the stage for the steps that will
 > follow, there is no order problem here.

(My review missed the typo:  "when each an header")

>>      From what I can tell, this entire paragraph should be moved toward

The 'recommendation for moving text was especially about the 'more than 
one' text.

 >           We ended up with the original text
 > because too many people were reading "the authentication service" to
 > mean "a proxy server or other intermediary", and by using the longer
 > construction, we are reminding readers that the authentication
 > service role may be instantiated by various entities in the
 > architecture. I don't believe this construction as given here is too
 > difficult to "grok"; it is not repeated in the steps below, and is
 > only here to emphasize the flexibility of the role.

Your explanation suggests deeper problems with reader comprehension.

In any event:

*The immediate problem is that the steps are part of the architecture, 
independent of implementation details.  So by saying 'entities 
instantiating' the document is stepping into sounding like it is talking 
about implementation.

There is a general challenge in the IETF, and elsewhere, in creating and 
maintaining clarity about networking architectures -- which are 
abstractions -- as distinct from the many ways they can be implemented. 
IETF specifications should encourage clarity, not add to the confusion.*

 >      By following the procedures in
 > Section 7.

That's nice.  A shame the citation isn't in the step, so the reader will 
have some clue.  *Also, Section 7 does not define clear, complete and 
deterministic (interoperable) procedures.*

Given the complexities of figuring out what identifier is to be 
validated, this step should be in two parts.

The first is to get the identifier. The above text seems to indicate the 
identifier always comes from the From: header field, but I believe that 
is not correct, given comments elsewhere in the document and in this 
review exchange.

The second is to assess 'authority' over it -- although I suspect that 
question is the wrong one, where the right one is *authorization* to 
validate the use of the identifier.  And that's a significant difference.

 >    It is not out of place in
 > the process that authentication services must complete, it is given
 > at exactly the point where it needs to happen. Before you can
 > ascertain whether or not you are authoritative for an identity, you
 > need to have the identity in a canonical form.

Canonicalization is a relatively complex issue for this activity. 
(Among its complexities are the tradeoffs among loss of information, 
ease of use, and robustness against transit behaviors.)

One can, of course, specify a series of steps that fully expand all the 
details inline.  That's like programming without subroutines.  However 
humans comprehend sequences better when they are presented with more 
coherence and brevity, versus presentation of all the fine-grained 
details in an extended sequence.  That is, when the steps can be seen 
easily.  One of the many downsides of expanding everything inline is 
that the reader is likely to lose their sense of the overall sequence.

Move canonicalization to its own subsection and then just cite it here.

 >    A similar comment also appears in Section 7.
 > I'd rather keep the "or not" with the "whether." Consulting the
 > relevant entry on "whether" vs. "whether or not" in an English usage
 > dictionary (Merriam Webster) it notes that "the use of 'or not' is
 > more than 300 years old and is common among educated English speakers
 > and writers. It is, in short, perfectly good, idiomatic English."
 > More to the point, I am really unsure what the value would be in
 > tagging stylistic decisions like this that can easily go either way
 > in a review of a technical specification - other than in so far as it
 > makes the review just a little longer and gives the person answering
 > it just a little more work to do. That goes double for flagging this
 > as an "issue" twice.

This is, of course, purely a stylistic point:  But again, the issue is 
not whether something is legal or has precedent, but whether it is 
constructive to the document's purpose.

In this case the question is whether the 'or not' adds information.  In 
some usages it does.  This is not one of those.  (cf, bloat. I realize 
you have already seen a number of such comments from me, but I figure it 
can't do any harm to keep repeating it...)

 >      Well, if it's flagged here, why not flag it back

That's an interesting model you seem to be asserting:  A problem isn't a 
problem unless it is properly cited at its first occurrence or at all 
its occurrence or...?  Really, Jon?

This is where I noted it or where I finally decided it was worth 
commenting on, or...   So please explain: What is the intended benefit 
of criticizing which occurrence got the comment?

 > in section 3, for the sentence, "Since the primary identifier of the
 > sender of a SIP request, the From header field, can be populated
 > arbitrarily by the controller of a user agent, impersonation is very
 > simple today in many environments." The sender of a SIP request is
 > the entity that instantiates (learn to love it) the user agent client
 > role in a SIP transaction. Practically speaking, that could be an
 > intermediary in some cases, but it is most commonly an endpoint under
 > the control of a calling user. Anyway, I don't think there's any
 > ambiguity about what "sender" means here, especially given the
 > earlier usage in Section 3. It is as you note pretty common in SIP
 > specs.

There is a basic lack of semantic clarity with the word 'sender' in any 
store-and-forward networking environment.  Everyone is a sender, except 
maybe the last guy in the sequence.  As a consequence, the word 'sender' 
needs to be used only in very precise ways, such as calling a client a 
sender (unless it's a receiver...).

In this case, the specific referent for the term was unclear to me. That 
raises the odds it will be unclear for some other readers.  If you don't 
care about clarity for a broad base of readers, then sure, ignore my 
concern.

 > This requests the removal of some non-normative text that gives
 > examples of how an authentication  service might authenticate the
 > sender of a message. Why this text should be "pedagogical" is a bit
 > obscure to me, as is why it would be a bad thing if it were - the
 > examples that follow are the ways that this step will probably be
 > accomplished, though we don't want to mandate any one in particular.

Examples are pedagogy.  The provide legal and/or plausible and/or 
relevant details to improve the reader's understand of the general point 
being described.

Putting pedagogy in the middle of the specification of a sequence 
invites reader distraction.  When pedagogy is needed, put it in the 
discussion about the sequence that normally comes after specification of 
the sequence.

>> not' does not flow from the preceding text in the sentence.

{{ No response from Jon. }}

 >    The end of this step reads "See
 > Section 12 for information on how the Date header field assists
 > verifiers." That answers "why?" It would be nice if the line-by-line
 > review here could keep state for half a minute and go back and remove
 > comments when they are answered immediately afterwards. [$]

Then cite section 12, so the reader can get easily linked to the 
explanation.

However Section 12 is a long and varied section and a citation to all of 
it isn't very helpful.  I suspect you mean Section 12.1.

 >      This is the only use of the term
 > "non-repudiation" in rfc4474bis-10, and the term does not appear in
 > RFC7375 or RFC7340, as non-repudiation is not a requirement needed to
 > address the threats for which STIR was designed. While PASSporT
 > contains some language about its potential use for non-repudiation,
 > do note the first paragraph of Section 7.2 of PASSporT. So in short,
 > I'm not aware that STIR has or has ever intended to have that
 > "feature".

Oh boy...

1. First sentence in Passport:

       This document defines a token format for verifying with non-
     repudiation the sender of and authorization to send information
     related to the originator of personal communications.

2. 7.2.  Solution Considerations

     It should be recognized that the use of this token should not, in
     it's own right, be considered a full solution for absolute non-
     repudiation of the persona being asserted.

     {{which implies that it *does* serve as a partial solution for
     non-repudiation. /d}}

Passport was created for STIR.  STIR uses Passport.  STIR documents do 
not declare their use of a subset of passport, nevermind what that 
subset is.

 >      indeed the sentence containing this
 > guidance says "(see Section 9)" at end of it. It is referring to
 > specification text elsewhere in the document, but here in these
 > steps, we do give some high level notion of what you're supposed to
 > do in addition to giving a pointer to where the behavior is fully
 > detailed.

 >    Once again, a line-by-line review needs to be able to read
 > literally the next sentence, which contains the "specific pointer" to
 > Section 8. [$]

Both a pointer *and* a redundant summary of what will be found at the 
pointer.  But only syntax.  No reference to semantics.

>>>    When however an authentication service creates a PASSporT that uses

{{ No response from Jon. }}

 >      If we let the sentence continue, it will clarify that
 > it refers to those cases where the the request "will be rejected by
 > the verification service on the receiving side" with a 4xx status
 > code, after which it gives some guidance about what is to be done in
 > those cases. Though of course, the sentence can't finish its thought,
 > as the review interrupts yet again after "the receiving side" with
 > the insistance that "'on the receiving side' is redundant. Remove it.
 > Where else is there a verification service?" and then of course again
 > before the end of the sentence to complain that the text here is
 > "descriptive" and wondering "where is this SIP behavior documented in
 > the spec?" Unsurprisingly, the text associated with sending a 438 in
 > the backwards direction is to be found in the verification service
 > behavior (5.2, Step 5 is a good place to start), though the formal
 > defintions of the error codes are in 13.3. But the review here would
 > benefit from letting a sentence end before objecting to it. [$]

The constant reference to my including a comment in a way that broke up 
the text and gosh if only I'd read a bit further I'd have seen the 
answer, suffers from several problems:

   1) Of course I read the whole thing.

   2) 'Letting the sentence continue" does not alter my assessment.

   3) I've placed the comment in order to make its referent clear.

Saying 'in some cases' requires very explicit indication of what those 
cases are.  The text doesn't do that, though I understand the author 
thinks it does.  This reader doesn't.  If one experienced reader is 
confused about something, what do we think the odds are that other, 
less-experienced readers will be?...

>> "on the receiving side" is redundant. Remove it.  Where else is there a

Just realized:  we again have confusion about who is doing what.  The 
STIR verification entity does not reject requests.  If reports a failed 
verification to its client, which is probably the system component that 
*does* issue the rejection.

>> This is offered as descriptive text here. Where is this SIP behavior

{{ No response from Jon. }}

 >      This is why, when
 > we're speaking strictly, we say things like "the entity which
 > instantiates the role of the authentication service" instead of "the
 > authentication service." If that entity is a proxy server, then yes,
 > in certain SIP cases, even though it is an intermediary, it can
 > resend a request in response to certain failed response codes it
 > receives. So when the review says "hence it doesn't do retries. All
 > of this needs to be recast in terms that match the specified
 > architecture", it does do retries and it does match the architecture.
 > This behavior entered the specification as a result of specific
 > issues seen the wild with early deployments of this code, and while
 > the review objects, "This is just guessing. Protocols that do
 > guessing don't work very well" and that "This interaction needs to be
 > re-specified to be deterministic", it is believed that this behavior
 > works and that it is specified tightly enough. The same problem with
 > "the entity which instantiates the role of the authentication
 > service" vs. "the authentication service" is why the objection in the
 > review to the text that "the authentication service MUST forward the
 > message" is similarly misguided.

The response again indicates confusion about the difference between the 
activities of a STIR architectural component, versus a range of ways 
that component might be implemented.

>> terms that match the specified architecture.

{{ No response from Jon. }}

>> This interaction needs to be re-specified to be deterministic.

{{ No response from Jon. }}

>> it doesn't do forwarding.

{{ No response from Jon. }}

 >    The review interrupts
 > the sentence halfway through with "redundant detail." I don't think a
 > high-level introductory statement counts as "detail". Is it redundant
 > to begin a section on "Verifier Behavior" with a sentence making it
 > clear that we're now into then business of defining the logical role
 > of the verifier, or is it simply setting the stage for people who
 > happen to skip to the top of that section and start reading? I don't
 > see a need for any change there, any more than I do at the start of
 > Section 4, which is titled "Overview of Operations" and begins with
 > the sentence "This section provides an informative (non-normative)
 > high-level overview of the mechanisms described in this document." Or
 > that the section titled, "Changes from RFC4474" has a starting
 > sentence that reads "the following are the salient changes from the
 > original RFC4474." This is normal specmanship, and hardly a matter
 > that warrants being flagged in a review.

>>>    message containing one or more Identity headers, it inspects the

And, again, the verifier does not receive the SIP message...

 >      actually, what Step 5 says is that
 > "the verification of an Identity header does not entail any
 > particular treatment of the request", that "this specification does
 > not propose any authorization policy" and that "local policy" is
 > responsible for deciding what is authorized. Step 5 does talk a bit
 > about circumstances in which an Identity header field value is
 > "invalid" - but the text is also clear that it proposes no
 > authorization decision based on "the presence of an invalid Identity
 > header."

 >      The sentence
 > in full reads "not support an Identity header present in a request
 > due to the presence of an unsupported 'ppt' parameter." Interjecting
 > "what does this mean" in the middle of a sentence when the
 > continuation of a sentence tells you what it means is a
 > counterproductive method of review, instances of which occur here
 > with mounting frequency. You don't support an Identity header (field
 > value, really) if it contains a "ppt" you don't support. [$]

So it's not the header field that isn't supported, it's one of it's 
parameters.  And yes, that's an important semantic difference.

Perhaps what is meant is that processing of the Identity header fails 
because a parameter in it is not supported?

 >      I'll agree that this isn't
 > motivated in RFC4474bis-10. It is there for forward compatibility; we
 > imagine that extensions (different "ppt"s) might be included in a
 > message by different authentication services, or that different trust
 > anchors might provide Identity headers that would be trusted by
 > different recipients. We're not really going down those paths at the
 > moment, we just didn't want to close the door on them. Still, I can
 > see it might be helpful to have a paragraph of (gasp) foward-looking
 > motivation about future work for this somewhere in the spec -
 > probably in Section 9 (on extensibility).

 >  I don't think it is harmful here to
 > reinforce that the parameter is optional, but that nonetheless, if
 > present, it MUST be inspected. The review furthermore asks of "'any'
 > can there be more than one?  If only one then perhaps:" The review
 > here doesn't like "the verifier MUST inspect any optional 'ppt'
 > parameter," as the use of "any" here only connotes the possibility of
 > "ppt"'s absence, rather than a potential plurality. I don't think
 > there's any confusion in the English usage there.

 >      While I highly doubt this is unclear, for "below" we can say
 > "with Step 2". The "abnormal" thing that happens is that you have
 > special handling for the presence of a supported or unsupported
 > "ppt." We could try instead of "normal" something like "default" or
 > "baseline" or whatever, but I think "normal" is fine. This contention
 > over what is "normal" continues with the review's claim that "it
 > appears that ppt does not affect processing, as long as the ppt is
 > 'supported'." This comments on a sentence that mentions that when a
 > supported 'ppt' parameter value is present, you do the "variations"
 > in Step 5. Step 5 has clear if-then handling for a supported ppt:

 > If a "ppt" parameter is present (and per Step 1, is understood), the
 > verifier follows the procedures for that "ppt" (see Section 9).
 > > That is the "variation" alluded to above. How this adds up to the
 > claim that a supported "ppt" does not affect processing is beyond me.

>> is the 'below' here different from the one before it?

{{ No response from Jon. }}

>>     From the above text, it appears that ppt does not affect processing,
>> as long as the ppt is "supported".  That is, an absent ppt and a valid
>> ppt both produce the same sequence 'below'.

{{ No response from Jon. }}

>>        Step 2:  Signature Scope

{{ No response from Jon. }}

I'm noting this here, but he didn't comment on them anywhere, from what 
I've seen.

So I'll clarify why the extra labeling matters:  It provides a semantic 
tag to the step and makes it easier to look over the entire sequence of 
labels and quickly understand the overall process.

 >      The answer is that you're going to do either one
 > or the other, but not both, between Step 1 and Step 3. Yes, telephone
 > numbers and domain names are different, but dealing with one or the
 > other is what you do at this stage of the process: it is the same
 > process otherwise. I can't see any other useful way to organize or
 > specify this behavior. I also don't see what possible problem someone
 > might have with this. "Why?" questions like this about spec
 > organization are very easy to ask, take a lot of thought to answer,
 > and ultimately have no impact on the technology we are specifying
 > here.

For starters, I don't see how the process in 7.2 determines between the 
two types of identifiers, nor do I see a process here that makes the 
selection, nor do I see directives about what to do with the different 
results.

 > 5.2 On Step 3, the review denounces the soft guidance in the spec
 > that a verifier merely "should" consider a credential for this header
 > unsupported if it does not support the credential described in the
 > "info" parameter. "Only should? Why???" Well, as the reference to 6.2
 > in the previous sentence would reveal if followed, verifiers may have
 > alternative means to gain access to credentials associated with an
 > identity than the contents of the "info" parameter, "such as an
 > offline store of periodically-updated credentials" or something. So
 > discovering the credential though "info" is only a SHOULD in section
 > 6.2, which trickles down to here. Line-by-line is not helping here.

"should" is not 'soft' guidance.  or is 'should' not meant normatively? 
(It's so difficult to tell, sometimes.)

 > 5.2 Step 3 "verifier returns responses?" Well, yes, in the sense that
 > "the entity that instantiates the verification service role" returns
 > responses. Note that we have the same language here in 5.2 as we did
 > in 5.1 right before the steps start to remind readers of this.

 >      Well, there was an earlier discussion of
 > authentication service behavior. This is a discussion of verification
 > service behavior. They aren't the same discussion. Things that the
 > review flagged as missing from that part are present here, because we
 > are describing the behavior of a different component of the
 > architecture.

 >      If "ppt" is present, all that will mean is that
 > potentially additionally headers (JWT headers that is) will be
 > present, which correspond to components of a SIP request. Any
 > PASSporT will always be a superset of the "bare minimum" headers and
 > claims, so really what the "ppt" means is that something in addition
 > to those has been signed. It would be as if, say, DKIM allowed one to
 > specify a list of header fields that were signed in an "h="
 > parameter, which then listed the email headers in question. Except in
 > our case, it assumes a baseline set of headers, and the "ppt" is
 > effectively a profile that implies what additional headers have been
 > included in the scope of the signature. I understand why it might
 > seem like "an outstandingly bad idea" and in fact for years - maybe
 > more than a decade - I held out against having anything but a fixed
 > signature. Our "bare minimum" is the compromise that allowed us to
 > move forward, while accommodating some important applications that
 > participants in the working group want to apply this to with "ppt"
 > extensions. I would prefer a "single algorithm", and indeed I think
 > we do have one as you suggest, one where "components of the algorithm
 > have branches." "ppt" is just one of those branches.

The response, here, is enlightening for just how complicated the model 
appears to be.  Lots of dependencies and conditionals to process 
through.  Or at least, that's how I read what it means...

(For reference, DKIM's h= is always present; it doesn't depend on other 
meta-constructs being present.  And while one can debate the efficacy, 
there's a minimum set of header fields required for h=, too.)

By the way, I hope that the ppt profiles doesn't "imply" the set of 
headers fields that are signed, but that the profile actually and 
explicitly specifies them...

 >      Whether we
 > consider the process of generating and validating the signature to be
 > one step or two seems like a very minor question to me: there's no
 > ambiguity that you generate and then validate, regardless of whether
 > from an organizational perspective we call that one step or two. Lots
 > of the other steps are also composed of multiple discrete and
 > separable actions. On matters this small it's hard to justify
 > changing it or keeping it. (For the technical question posed in this
 > same interjection, see the technical responses below).

OK.  Why not make the entire algorithm one step?

The answer is clarity.  The suggestion I'm making is for explicitly 
distinguishing two portions of the sequence that have completely 
different details and semantics.

 >      It means that there is a
 > very real security difference between Identity not being used at all
 > (which means you have no assurance either way) and Identity fields
 > being present but broken (which means someone is trying to use the
 > mechanism, and either an operational or security problem has arisen).
 > Why on earth this would entail that "the entire transfer environment
 > is expected and required to convey Identity fields perfectly, all the
 > time" is beyond me. Identity headers will be dropped by some existing
 > devices today which strip any headers they don't recognize, for
 > example. And "canon" will fill in gaps in some other cases.

The stated 'which means' interpretation here suggests a basic failure in 
the group's analysis of operational errors, as described in my comments 
earlier in this note.

 >      This text is giving
 > guidance on what happens at the end of this process. I disagree that
 > it belongs earlier, but I can see that it isn't a part of Step 5 as
 > such. Maybe I'll put in some clear divider to indicate where Step 5
 > ends.

 >      I don't think it is harmful to reinforce that
 > the "canon" parameter is optional. The review then goes on to also
 > recommend removing "of the Identity header" as "there is no other
 > canon parameter" than the one associated with that header. I for one
 > do not feel that in the introductory sentence of a section, providing
 > a bit of broader context and reinforcing what we hopefully already
 > know for the benefit of people who skipped to this section via a
 > pointer from elsewhere or what have you is harmful - I think it is
 > actually good specmanship. The review however really doubles down on
 > this: "But really I suspect that even the 'if' is unnecessary. The
 > optionality has been established elsewhere. The task here is merely
 > to specify what is in a canon." So the review proposes that 5.2.1
 > instead start with "The 'canon' parameter contains a base64 encoding
 > of the header and claim..." etc. Comparing that to the existing text,
 > I think the context that the existing text provides is valuable
 > enough to warrant retaining it, over these forceful objections.

>> has been established elsewhere.  The task here is merely to specify what

{{ No response from Jon. }}

 >      I do not feel that mentioning the fact
 > that 'canon' contains a base64 encoding of the PASSporT header and
 > claims is in any meaningful sense a "re-specification" of canon. A
 > respecification would say, like, what those headers and claims are
 > and how you build them. Providing basic and essential high-level
 > context is not a reprimand-worthy offense.

Again:  Each time a specification detail is repeated elsewhere in the 
document is an opportunity to get it wrong and a burden to search and 
find when the details change.

 > There are not multiple "formats," but applying the canonicalization
 > algorithm to telephone number representations will yield results that
 > could be variable, because of matters of local policy described in
 > Section 7.2. So if there's a problem with that, it's in 7.2, not in
 > this section - the pluralization of "formats" is just an artifact of
 > the "any" in the sentence construction.

"canonical telephone number formats"  does not mean multiple formats?  I 
don't understand.

Worse, the idea that a specification seeking standardization would 
include an algorithm that can produce variable results due to 'local 
policy' is a very basic error in the approach to doing standardization.

*As soon as one says 'local policy' for anything other that a generic 
and non-normative discussion, one has stepped out of the sandbox in 
which the specification controls and, therefore, has stepped out of the 
specification.  In other words, local policy for something like this 
needs to be out of scope.*

 >       I think
 > this is a good place to say what canon is for; it is the "canon"
 > section, the only one dedicated to it in the document. Previously,
 > 5.1 said that "The information in "canon" is useful on the
 > verification side for debugging errors," and here in the verification
 > side it makes sense to state what use there is to be made of it.
 > Given the way the spec is organized now, putting a statement to this
 > effect here makes more sense than placing this anywhere in section 7,
 > say, since that really only deals with canonicalizing the
 > identifiers.

That is a bit like saying that a section of how to drive a car is a good 
place to explain what a car is for.  Or by having extensive discourse on 
concepts of nutrition in the middle of a recipe for making a dish.  In 
other worse, it isn't at all a good idea.

Discussion of purpose is different from discussing procedure.

There should be coherent and integration discussions about purpose 
earlier, before later diving into the many details of procedures.

 >      It really helps if you read the rest of the
 > sentence. What it says is that you MAY compute it "-before-
 > performing any cryptographic functions in order to ascertain whether
 > or not the two ends agree on the canonical form." Clear? What
 > implementations MAY do is to perform that comparison -before- any
 > hard number crunching. Rather than doing it after. Reading the whole
 > sentence helps. [$]

Interesting.  The problem here is the cascading and backward dependency 
sequence in the way the sentence is constructed.  It does lend itself to 
easy comprehension.

>> This is talking about actions during Step 4.  Move it to Step 4!

{{ No response from Jon. }}

 >      I think the distinction between a
 > security violation, which is a necessary verification failure, and
 > some operational hijinx like intermediaries tinkering with the Date
 > header when regenerating a SIP request, which is an unnecessary
 > verification failure, is worth preserving.

 >      Indeed, as the last paragraph of Section 1 states, the
 > "revisited" in "STIR" derived from the fact that "RFC 4474 also
 > provided a signature over material that intermediaries in existing
 > deployments commonly altered," which led to unnecessary verification
 > failures, and for us to revisit the signature scope. The signature
 > scope we have now is the best one we think we can propose. We do
 > believe that "canon" helps to mitigate the meaningful causes of
 > unnecessary failures. The overall mechanism has gone through a great
 > deal of working group scrutiny and also implementation and deployment
 > testing. I've personally run it over live SIP networks. Casting vague
 > doubt on it, while it is easy to do and it pads out the list of
 > comments, is not persuasive. This is I think the only place so far in
 > this review where I have asked for more information, but if you
 > actually have something substantive to say about this, please say it,
 > rather than just darkly hinting at stuff you know that we presumably
 > don't.

"The signature scope we have now is the best one we think we can 
propose" is fine.  I'm not expressing concern over the details of the 
algorithm here, but on the persistent view that receive-side failures 
will only be due to the intervention of a bad actor.

>>>    potentially a set of domains enumerated by the credential.

{{ No response from Jon. }}

 >      The notion that a credential's scope
 > might cover a single domain or "potentially" a set of domains
 > suggests that the former is common and well understood and the latter
 > is something we're endorsing a bit less heartily. Although the review
 > speculates a bit about whether a "set of domains" means sub-domains
 > under a higher-level domain, that isn't really material to the
 > language here. Taking a step back, I can see how this might be
 > confusing, though - could be worth a quick fix.

>>       Similarly for telephone numbers, a credential can represent one or
>> a range of numbers.

 >      While the latter is slightly shorter, the value of
 > this sort of wordsmithing is unclear. It loses the connotation that a
 > credential "represents authority over" those telephone numbers. The
 > credential doesn't "represent" those telephone numbers.

The sentence covers only credentials pertaining to telephone numbers. 
This is a pivotal point to the scope of the sentence.  But it's only 
implied by the original form while being made the predicate for the 
suggested text.  So in fact clarity is exactly the point behind the 
suggestion.

 >      It would be, which is why we have a stir-certs
 > specification that gives a credential system that we intend to use
 > for initial implementation. RFC4474bis is pretty clear that the
 > aggregate of it, stir-passport, and stir-certs is required for
 > implementation. Historically, those two specifications effectively
 > split out of RFC4474bis (though stir-passport first merged in from
 > the verified-token draft, it then merged out again).

Except that stir-certs is not a specification.

And even if it were, it's not linked into the topic here properly. 
Instead, there's more pedagogy than specification, where the pedagogy is 
almost certainly redundant with was is, or should be, in stir-certs...

 >     I would think that those examples might help to inform
 > implementers who are trying to decide what kind of tools to provide

Interesting view.  And it might work well, for a companion document 
talking about such issues.

But this is a specification, not an implementation guide.  Giving 
guidance about the implementation of details that are out of scope is 
doubly out of scope.

 > to operators, at least what sorts of building blocks might be in play
 > in expressing that policy, or what protocol tools would be needed to
 > extract elements that the policy could act upon. Or maybe we as
 > specifiers thought that this would be a sound foundation for a
 > policy, and while we don't want to give it normative force, we want
 > to put it out there so that implementers and operators might consider
 > it as a practice, if it happens to fit with their existing model. We
 > might also think it is worth mentioning corner cases (like anonymity)
 > that people might overlook in implementation otherwise. But... I
 > really don't think there's any reason that the inclusive of a
 > non-normative example requires a defense like this, nor do I think
 > that the requirement the review expresses here is a valid one for
 > IETF specifications.

It shouldn't require a defense because text like that shouldn't be 
anywhere near text that is specifying an Internet protocol.

 >      Um. You know I think either reads okay, strangely
 > enough. I think I maybe like "for" better, the credentials are "for"
 > those authorities, rather than merely received "from" them. Maybe
 > "corresponding to" would be better.

The two words create fundamentally different meanings.  If the actually 
intended meaning is both, then say that.  Otherwise, choose the word 
that means precisely what is intended.

 >      I don't think a parenthetical mention that the
 > "info" parameter is described in the next section harms the
 > comprehensibility of the document in any way.

 >       As I rememeber
 > discussing this with the reviewer on at least one previous occasion,
 > I do gather this is a subject of some confusion. Relying parties
 > trust these credentials because they trust the trust anchor that
 > issued these credentials. They do not trust them because of the
 > pointer they used to retrieve the credential, which may in fact be to
 > an untrusted service. Who cares? If you find a certificate on a
 > crumpled up piece of paper in a bus station and manually type it into
 > your computer, you trust things signed with it (or not) based on your
 > trust for the anchor that issued the credential and the scope of the
 > authority that the anchor assigned to the credential. I seem to
 > recall the reviewer being quickly convinced of this the last time we
 > discussed it, and I can only assume this relapse is due to the fact
 > that credential trust issues here are deferred to stir-certs rather
 > than included in rfc4474bis. Although the review goes on to say that
 > "A complete specification of a STIR service needs to include a
 > publicly-usable key certification mechanism, a la DANE or DKIM or the
 > like," that is really a document organization question, as stir-certs
 > is intended to provide that.

What is missing is a clear specification for this essential service 
component, including *very* clear explanations of the trust model -- 
presumably using the above as a basis.  It then needs a very diligent 
vetting by security folks, in terms of precedence of use, to provide a 
basis for believing it will work, and expected scaling issues.

In effect, the model appears to emulate something like WEB certs, which 
have demonstrated extremely poor operational properties, or maybe 
DNSSec, (or maybe DANE) which is expected to do better, but absent a 
precise technical specification for this model, it's all just 
conjecture.  In any event, this is not something to bury with a few, 
terse references in the middle of this specification here.

>> or another piece of the base STIR specifications.

{{ No response from Jon. }}

 >     No, it is saying that this document
 > tells you how to validate what goes over the wire, but that it is a
 > matter of local policy who you trust and why. We're not here to say
 > "all implementations of STIR shall trust the following trust anchor"
 > or what have you. It is up the conscience of the individual
 > churchgoer. This is no different than it is for web PKI. There is a
 > lot of diversity of opinion about who will issue those credentials
 > and what their scope will be, and the stir-certs spec gives some
 > guidance on how those scopes would be managed for a couple of
 > initially envisioned architectures. But the point is, the fields that
 > go in PASSporT and the semantics of the SIP Identity header field
 > value will not be any different as a result of those different
 > architectures. This is simple matter of design modularity. I doubt
 > there is some lurking flaw here, this has probably been the single
 > most vetted and scrutinized aspect of the design.

*The response shows a confusion about validation and trust.

Validation is the task of STIR.  Within the scope of establishing 
validation -- that is, within the standardized and interoperable details 
of an authentication mechanism like STIR -- there *must* be a semantic 
component provided which establishes the authority of the entity 
asserting validity to make that assertion.:  The premise of an 
authentication mechanism is clarity about the authority of the entity 
vouching for the use of the key.

This is entirely different from the trust component which assesses 
whether that entity is a good actor or not (or whether the authorized 
entity doing the signing is a good actor or not.)*

 >      This commentary
 > is inserted into a sentence directly before the one reading "Further
 > consideration of how to cache credentials is deferred to the
 > credential mechanism specifications."

Another good reason to remove it.

 >      To my chagrin, the
 > latter is at least partly true. There remain some references to the
 > Identity-Info header that still need to be ripped out: two in 6.3 and
 > one in 7.3. A mention in 6.2 still gives a reason code for 436 as
 > "Bad Identity-Info" as well. I'd be willing to concede that counts as
 > "many." I am however less persuaded that the 'info' parameter is not
 > specified. It is introduced in Section 3, instructions on how to
 > include it are given in Section 5.1 Step 4, instructions on how to
 > process it are given in Section 5.2 Step 3 with a helpful forward
 > reference to 6.2. The guidance on 'info' given in 6.3 seems perfectly
 > adequate, and its abnf is indeed given in Section 8. The allegation
 > in the review of 6.3 that there is some deficiency in the
 > specification of 'alg' and 'ppt' is, as far as I can tell, baseless -
 > 'alg' has not even been mentioned in the specification yet by section
 > 6.3 in any context. But definitely we need to remove those extraneous
 > references to Identity-Info.
     >

>> and where to go to find its definition.

{{ No response*S* from Jon. }}

 >      I'm not aware there are any forward references in 6.3.

 >       Since this section primarily discusses the conditions in which
 > the URI found in an 'info' parameter can be deferenced, this can
 > hardly be considered "defining" its contents, which have long since
 > been defined (in particular in places like 5.1 Step 4, at least until
 > we get the final word in Section 8).

>> mean?  How is the signer to know what is dereferenceable by the verifier?

{{ No response from Jon. }}

 >      That would certainly simplify the
 > architecture, and in practical deployments, that may effectively be
 > decided by fiat. The suggestion though that this is the "real need"
 > is an unnecessary limitation. Later in 6.3 this returns as "Looks
 > like this needs to define a STIR Credential Registry." While I
 > wouldn't mind if one of those existed, it is not necessary for the
 > deployment of STIR, and should not be introduced as a required
 > component of the architecture.

*The operational history of certificate-based services is highly 
problematic.  For a criticial infrastructure service like STIR, the 
technical design of the cert service is not something that can be 
deferred and treated merely as a matter of operational design.*

 >      While this section says little, the
 > little it does say constrains external credential systems enough that
 > it is worth retaining. The requirements here are, for example,
 > discussed in the stir-certs document. The review rightly notes that
 > "the entire topic appears to be larger than this specification," and
 > this specification doesn't suggest otherwise.

The section does indeed say little.  Enough to give the impression that 
it is covering its topic, but too little to be of sufficient help.

>> to be larger than this specification.

{{ No response from Jon. }}

 >      As the text here points to existing RFcs in this space,
 > and drafts tailored to provide this specific capability for STIR, it
 > is baffling why the review alleges that this is "not appropriate for
 > inclusion inside a technical specification," nor why moving such
 > material to a separate document would more useful than keeping it
 > here.

Because a specification is not a review document. And the review text 
about what exists 'today' is likely to quickly be out of date.  It also 
seems odd to have a 'requirements' section this late in the document...

>> the above isn't 'requirements'.

{{ No response from Jon. }}

 > The scope of a credential is the scope of its authority: in this
 > context the identifiers for which the credential is authorized to
 > sign. Scope is discussed earlier in 6.2 and the first paragraph of
 > 6.1 (probably the best place to look).

then please say that.

>> Looks like this needs to define a STIR Credential Registry.

{{ No response from Jon. }}

 >      This is in response to some text about
 > how the "associated credentials will support the mandatory signing
 > algorithm(s) required by PASSporT." This is simply a reference to the
 > keying material associated with the credential actually supporting
 > ECDSA as required by PASSporT. If you have a credential with an RSA
 > key, like an old fashioned certificate, you will not be compliant.

This is fun.  A document that is supposed to be a protocol specification 
and is specifying neither the cert mechanism details nor the 'passport' 
mechanism details is making 'requirements' demands on both.  That 
equates to having some specification of each of them buried in the 
middle of this document.

 >      I think
 > the existing text is much more specific than the proposed edit, and
 > while the edit may be more concise, it does not attest the
 > possibility that "business arrangements or similar constraints" may
 > be required to enforce a trust anchor in some deployments.

Oh yes.  It /is/ more specific.  That's the problem.  It is diving into 
detail that isn't appropriate for the protocol specification task of 
this document.

 >      STIR itself primarily focuses on telephone numbers
 > and the problems of impersonation related to them. We went back and
 > forth on the charter about whether to even allow this spec to cover
 > regular SIP URIs as well. Ultimately, it does, though they have been
 > second-class citizens throughout the spec's development. The recent
 > restructuring of Section 7 and the introduction of the URI
 > normalization section were intended to rectify that a bit. So perhaps
 > it isn't as true anymore. But in terms of STIR's overall goal,
 > telephone numbers are definitely the primary focus.

Actually, this specification does /not/ "focus" on telephone numbers. 
It attempts to deal with both forms of identifier, although the way it 
does that is confusing.

To the extent that you think this document focuses on telephone numbers 
"and the problems of impersonation related to them" as distinct from 
other types of identifiers, please describe where and how this focus is 
established and maintained, because I really don't see it.

In additional, such a focus is probably a tactical mistake and probably 
a strategic one, especially given the many and varied claims of interest 
in providing for longer-term enhancements...

 >      Even in the spec,
 > "greenfield" is given in quotes to set it apart. While it's true that
 > the term does not appear elsewhere in the specification, and could be
 > discarded without doing any harm to readability, its presence does
 > not strike me as a problem either.

The response doesn't answer my question.  And my question made clear 
that I've no idea what the word is supposed to mean here or what 
justifies use of the word.

 >      I think the term
 > "guidance" is adequate and not ambiguous.

So, this section is only supposed to be a non-normative discussion of 
the topic?  It isn't supposed to provide normative detail?

 >      The
 > answer to that is so obvious that perhaps it is easy to miss. If your
 > environment uses PAI, then you take the identity value from there. If
 > it doesn't, you don't. This may sound glib, but it is actually
 > profoundly sound advice for the environments that actually do use
 > PAI. This has been much discussed on the list, even very recently. We
 > think the guidance here is sufficient.

 >       Especially here, this is nonsense.
 > What is local policy, as the spec says, is the decision of whether
 > you extract the identity from PAI or the From. There's still plenty
 > to be said about what you do once that policy decision has been made
 > one way or another. The notion that as soon as the words "local
 > policy" appear in a spec then you can't say further related to the
 > subject is a rule with no basis in practice or reality. Again, the
 > review urges that "To the extent there is a compelling need to
 > specify this alternative mechanism, do it in a separate
 > specification." No thanks, it's fine here. On similar grounds, the
 > review goes on to suggest that another helpful paragraph of mechanism
 > be removed because it mentions "local policy" in connection with the
 > "canon" parameter. No thanks.

*"What is local policy, as the spec says, is the decision of whether you 
extract the identity from PAI or the From"  is a perfect example of 
failing to ensure interoperability.  It is exactly the sort of thing 
that needs to have determinacy in sources of information.  The concept 
of "local" policy for such an action is an explicit statement that a 
participant has stepped outside the four walls of the standardization 
process.*

>>>    of the guidelines in Section 11.

{{ No response from Jon. }}

 >      Of course, the next sentence goes on
 > to start explaining what you do, with some nice normative text.
 > Similarly, the review then orders, "If there is an algorithm to
 > follow, specify it as an algorithm. Otherwise, this is non-normative
 > discussion and isn't very helpful here." And the very next sentence
 > gives the first step in an algorithm.

>> Otherwise, this is non-normative discussion and isn't very helpful here.

{{ No response from Jon. }}

 >      Specifications are apparently
 > forbidden from suggesting that something is rare or pervasive. There
 > are two ways that a telephone number can appear in the user part of a
 > SIP URI, and that one is more common than the other in contemporary
 > operations. It is true that this information would only be of little
 > use to implementers, because the scheme itself will tell you whether
 > or not the less common of these approaches is in use. And maybe over
 > time it would no longer be true. But is it even worth anyone's time
 > to suggest removing it? Will any implementer do something wrong
 > because those words are there? Will anyone be confused or understand
 > the aim of the specification less?

The essential point is confusing specification detail with operational 
detail, especially when the operational detail involves statistics and 
there is no data upon which to base the prediction.  Conflating the two 
types of text confuses both of them.

 >      I'm not aware
 > that there is any "heuristics part" of this mechanism to exile
 > elsewhere. There is one sentence that talks about just treating a
 > numeric string like a telephone number and seeing if it works - if
 > that's the heuristics part, then I think it doesn't take up a lot of
 > the reader's time.

Given the style of the prose that apparently is attempting to specify an 
algorithm, I can't tell whether the outcome is deterministic and 
interoperable.

 > 7.1 "'enroll'???" Yes, there is something called certificate
 > enrollment.

Some quick research shows the term tied to Microsoft products and to 
SCEP.  Google certainly does not produce results that shows it as ab 
otherwise-common term.

So here we are again, with a term of art being used that does not have a 
definitional anchor in this document, but apparently significant intent 
in its use.  So the reader is not safe to guess or ignore but is mostly 
being required to guess.

After review, the situation might be more interesting than I'd realized, 
since I can't find a definition of "authentication services", so I'm not 
even clear what function entity in the STIR architecture is being 
referenced and what its job is.

 >      This is a comment on a two-sentence, one
 > paragraph section which exists to give an external pointer to
 > stir-certs. It says that this stuff is "outside the scope of the
 > document." There are no "details" about enrolling in this section,
 > nor does it repeat information provided in 6.4 - it only mentions
 > that there is information in 6.4. This review comment does not even
 > identify any real issue.

 >      The To and From header field values (and the sneaky
 > P-Asserted-Identity header field value too) of SIP contain URIs. The
 > only meaningful distinction here is between a SIP URI and a TEL URI.
 > But you're always going to be extracting a telephone number from some
 > sort of URI.

Such a simple and even reasonable point.  And yet this far into the 
document I had not understood that, in spite of extremely detailed 
reading of the draft.  No doubt I'm the only reader who will suffer that 
confusion...

 >      Of course, since
 > the next sentence reads "That requires performing the following
 > steps," clearly performing those steps is what it means to "construct
 > a number string." But more importantly, the review question assumes
 > that a "number string" has already been identified, whereas the spec
 > text reads "once an implementation has identified a telephone
 > number." The distinction here is between a "telephone number" and a
 > "number string." The review though neatly twists this around to make
 > it sound like that distinction is not obvious in the sentence. [$]

The point behind my question is that the phrasing creates confusion.  At 
the least, the nature/purpose of the string to be constructed needs to 
be clarified.

 >      It's true that as the text reads now, we only strip a
 > leading "+". I'm not aware that there is any issue with an internal
 > "+". The review goes on to propose that we simply replace all the
 > fancy canonicalization stuff with a simple statement that one should
 > "Take the original string and remove any characters that do not
 > conform to the above format." This isn't really that far from what we
 > recommend, except for cases where you are converting from a dial
 > string or similar operation - which basically is a case where, as the
 > review says, you "tweak that trext for any cases that need to add
 > characters," as you typically just prepend characters when converting
 > from a dial string (though you may add some first, depends on the
 > string).

>>>       valid, globally-routable number with a leading country code.  If

{{ No response from Jon. }}

 > 7.2 Here the review pushes back more strongly than previously on the
 > whole idea of using steps to describe behavior. The review redas,
 > "the algorithm should be specified in the form of an algorithm,
 > rather than as normative prose," and goes on reading the steps to
 > add, "again, this isn't really a specification," "this kind of
 > language is not really a specification," and then "the above text
 > also is not a specification." But in other places, the review seems
 > to acknowledge that these steps do describe an algorithm, and it
 > merely suggests moving "commentary about the algorithm -- such as
 > 'these will appear...' to be outside of the algorithm specification."
 > > One of the symptoms of being "commentary" instead of specification is
 > language like "may involve," apparently. The spec here has a
 > normative statement about transforming the number into an E.164
 > format, which, a separate clause reads, "may involve transforming the
 > number from a dial string (see RFC3966)" or various other formats.
 > The spec text here is a true and useful statement: the number may be
 > a dial string (per RFC3966) and may need to be transformed into E.164
 > format. It won't always, or even usually (commonly!) be true that you
 > need to do that, but you might. Listing this in the step is useful.
 > Whatever prohibition the reviewer imagines that divides "commentary"
 > from "specification" in this fashion would be an onerous and
 > counterproductive constraint on IETF specifications. It is probably a
 > good warning though that "language like "except only" encourages
 > coding errors."

(I've left Jon's entire comment -- including it's context-setting text 
-- to show that he covers multiple review comment entries.  The placing 
here is for what I think is the last of the set.)

 >      It is true that we acknowledge it will be
 > possible for different entities to canonicalize numbers different
 > ways. This will happen in cases with private numbering plans, various
 > strange nationally-specific numbers (like emergency service numbers),
 > and some other corner cases. It is just our assessment that these
 > will not be vectors for enabling impersonation of calling party
 > numbers, and that they will be rare (as in, not "common") enough that
 > it won't impact operations significantly. Overwhelmingly, networks
 > will carry numbers in E.164 format, and the canonicalization pass
 > will be very light and straightforward. Our confidence in that
 > operational reality is the basis for the mechanism that we propose.
 > It has been scrutinized by, well, the people that actually operate
 > these systems. Also, because of "canon," the two networks will at
 > least be able to spot debugging errors here.

This guarantees non-interoperability, since the verifying entity won't 
know what to do to produce the same result.

>> possibilities that are outside the spec.

{{ No response from Jon. }}

>> Then tweak that text for any cases that need to add characters.

{{ No response from Jon. }}

 >      Um,
 > we'll fix that as "E.164", though probably the ref here is to
 > RFC3966.

 >   That's correct. I'm willing to ditch "and signing".

 >      It is significant
 > because canon helps to debug operational errors that arise from
 > canonicalization problems.

 >      Again, we don't think there is a practical
 > problem here. In cases where any form of meaningful inter-network
 > interoperability is possible, different sides of the call path will
 > arrive at the same decisions here, and in cases where they can't
 > agree on what a number is, they probably can't meaningfully even
 > route calls to each other, let alone sign calling party information.

The response seems to be saying that choice of normative language 
doesn't matter here because there will be private agreements to cover 
it.  In that case, remove the text from here, or include text that 
explicitly says the issue will be covered outside of the specification. 
(I don't think that's actually viable, in this case, for a public, 
interoperable protocols specification done in the IETF, but what the 
heck...)

 > The title obviously mirrors the title of 7.1, "Authority for
 > Telephone Names," and both refer to the authority that credentials
 > provide over the respective identifiers. Ultimately, we could say
 > that this authority devolves from ICANN, in the domain name case, and
 > trickles down through the TLD operators to the owners of second level
 > domains who go get credentials from certificate authorities today. So
 > actually, I'm not sure the subject of this section is so divorced
 > from the reviewer's reading as he supposes.

 > 7.3 The review here proposes for this section "splitting the
 > discussion to an earlier, non-normative section, and a section here
 > that simply specifies technical detail to perform." Sounds like that
 > would take some work, but the benefit of that split would be unclear.

focus.  clarity.

>>>    header with a domain signature, it must compare the domain portion of

{{ No response from Jon. }}

 >      The answer is that the
 > spec text this highlights talks not about credentials, but about the
 > way that SIP servers use identifiers, and how domain names are
 > encoded within SIP URIs in particular. The discussion that this
 > comment follows is about name subordination in SIP, not in
 > credentials. It is necessary to give some SIP guidance related to
 > name subordination as it may have implications for the use of
 > credentials and the scope of authority that would not otherwise be
 > obvious. The review goes to reiterate that "I suspect all of the
 > above detail is out of scope, given the way these specifications have
 > been partitioned," but the relevance of the discussion of NAPTR and
 > SRV processing to the domain names attested by credentials is pretty
 > obvious, I think.

>> these specifications have been partitioned.

{{ No response from Jon. }}

 >      The end of
 > the spec sentence here says, inevitably, "by following the procedures
 > defined in RFC 2818 [RFC2818], Section 3.1." So presumably the
 > "evaluation" actions described there are the ones that the verifier
 > takes in this case. That section also gives the "actions are to be
 > taken in response to the evaluation". Again, extending a document the
 > courtesy of reading the entire sentence is usually a good idea when
 > writing a review of this kind. [$]

Oh boy.

The cited section refers to values with very specific names, which don't 
match parameter/value names in the current document.  So the reference 
to using the procedures of Section 3.1 permits an approximation at best.

In addition, Section 3.1 uses the term 'matching', not 'evaluating', 
which is a more precise and appropriate semantic.

Next, Section 3.1 actually pints to RFC2459 for the meat of the work, 
which raises the question of why the current spec doesn't simply point 
to RFC2459.

Lastly, I thought that the history of domain name matching with certs 
has shown far too much rigidity about the domain string and that there 
has recently been quite a bit of work to permit matching in the face of 
valid variations.  Why isn't that recent work incorporated here?

>> Canonicalization for phone numbers and Normalization for URI.  Why the

{{ No response from Jon. }}

>>   transformation  -> transformations

{{ No response from Jon. }}

 >      This is also
 > a "what doesn't belong in specs" issue, but here presented
 > organizationally, as if an RFC is divided into sections about
 > "specification" and then non-normative sections. Where this is coming
 > from is, as usual, beyond me. The spec text in this section is the
 > only place in the document that we address either the normative or
 > informative dimensions of URI normalization.

 >      It is true that we don't give
 > the section, but the text is clear we are talking about the ABNF of
 > the "SIP and SIPS URI", and the rest of the sentence specifically
 > references the structure of that ABNF, including the "hostport"
 > component and the remaining elements. Reading to the end of the
 > sentence frequently resolves things that might appear ambiguous at
 > the beginning of a sentence. The review makes it to the end of the
 > sentence, actually, and locates the proper ABNF, because then the
 > review complains about the use of "including" when it precedes the
 > requirement to remove the uri-parameters and heads, as "By my reading
 > there isn't anything other than those two rules." Given that the
 > review had no difficulty locating the ABNF and the elements in
 > question, why ask "What about the ABNF requires any of what is
 > asserted here?" Why pretend that this was unclear or ambiguous? [$]

ad hominem.  always a pleasure.

Especially when the review comment was about nothing more than the lack 
of adequate precision in the reference, by repeating that referring to 
an entire document does not constitute a sufficiently narrow pointer.

>> "including"?  By my reading there isn't anything other than those two

{{ No response from Jon. }}

 >      I
 > don't believe it is more clear or helpful than the spec text as
 > written.

Oh boy.

>> In other words, just get <host>

{{ No response from Jon. }}

 >      We had considered using just
 > rfc822 style identifiers here, and discarding the scheme entirely. If
 > present, SIPS implies something valuable actually, especially when
 > the URI appears in the To header field value - it would be an
 > interesting security violation if an intermediary downgraded that
 > from SIPS to SIP in transit, as that has implications for the
 > hop-by-hop use of TLS. That much said, this sort of intermediary
 > meddling is not specifically in the scope of STIR, it is merely a
 > side effect of our work, but one worth preserving.

Every time language like "SIP or SIPS" or "SIP/SIPS" is used, there is 
no tailored language for one or the other.  Rather there is merely 
repetition adding unnecessary verbosity and possible distraction.

 >      If there's something
 > better to cite here, I'm happy to cite it. We're not going to
 > reinvent the wheel. Maybe I'll ask this question more broadly. This
 > text is among the newest in rfc4474bis, so it's good to have some
 > eyes on it.

When something doesn't do what is needed, it's not a case of doing 
'better'.  It is a case of doing what is needed.  Either by citation or 
by direct exposition.

 >      Indeed, there are some internationalized
 > environments where we expect normalization won't help, just as there
 > are some oddball telephone environments where canonicalization is
 > unlikely to help. We just think that there are operational
 > environments where this will all work without any problems. For the

Within the four walls of a protocol specification, there is a kind of 
perfection.  The protocol works where it works.  Where it doesn't work, 
it doesn't exist.

Referring to the places a protocol won't work properly might be useful 
during an opening discussion about the applicable environments for using 
the protocol.  But that does not include in the middle of the protocol's 
detailed specification.

At base, the issue here is, again, failing to treat activities that are 
out of scope as outside of the specification, and/or failing to move 
discussion of operational consideration to a /separate/ discussion of 
operational issues.

 > review, though, "This again raises the question of treating a broken
 > signature the same as no signature present." Here I can only point
 > once again to the text of rfc4474bis-10 section 5.2, in the last
 > paragraph, which states that "This specification does not propose any
 > authorization policy for user agents or proxy servers to follow based
 > on the presence of a valid Identity header, the presence of an
 > invalid Identity header," etc. At a protocol level, we believe it is
 > helpful to send a 438 when there are only invalid Identity headers in
 > a message, so we make that a MUST. But for the terminating side, that
 > is not a question of operational policy, that is a question of
 > getting the full "canon" for debugging purposes. For the originating
 > side, who is going to the trouble of signing these things in the
 > first place, merely ignoring an invalid signature silently and
 > proceeding as if no Identity was provided is not particularly helpful
 > - they should want to know that there is a failure, be it simply some
 > sort of misconfiguration or something untoward going on.

 >      Why is this information here? Because
 > we want to warn implementers about the potential for identifiers
 > without protocol schemes, including rfc822 identifiers, which we
 > expect might come from WebRTC interaction (like SIP -> WebRTC
 > gatewaying).

This sort of 'warning' is almost certain to have no practical effect on 
programmer behavior.  There are well-established reasons for this, at 
several levels.  So it's text that makes the author feel like they'd 
been diligent, but they haven't actually accomplished anything useful.

 >      Since constructing a
 > PASSporT entity is a step in constructing the SIP Identity header,
 > this is not such a confusing matter to me. But I'll take this as yet
 > another organizational suggestion that there should be a subsection
 > or what have you to contain the PASSporT-related text. It's not an
 > awful idea, but nor would it solve any particular problem.
 > Hypothetical changes like this are unlikely to have any impact on
 > implementation.

 >      The
 > idea that a bis of an existing RFC should not reference that RFC is
 > pretty removed from my experience at the IETF. The review instead
 > proposes that "this section should merely define what it defines and
 > not put it in terms of the earlier document." I don't think the text
 > here actually does put anything "in terms of the earlier document,"
 > it just has a one-paragraph introductory warning that this header
 > syntax is revising an existing bit of grammar.

The issue isn't 'reference' but rather concerns the distraction of 
'discussion' and of auditing the differences.

As for IETF experience with bis documents, the ones I've seen over the 
years were for documents that had a significant installed base.  The RFC 
in question here doesn't fit that model.

>> optional components of the Identity header field.

{{ No response from Jon. }}

>> names and then need prose text to explain their semantics.

{{ No response from Jon. }}

 >      The fact that before the
 > ABNF of the header there is a clear statement that this is "following
 > the ABNF [RFC4234] in RFC 3261 [RFC3261]", which defines all of those
 > elements, is clearly lost on the reviewer. [$]

Yes it was.  For one thing, it is usual when importing rules to state 
that rules are being important.  Specifications that are especially 
polite explicitly list the names of rules that are imported.

And again, citations should be as precise as possible, naming sections 
or sub-sections rather than entire documents.

>>>    is given as a quoted sequence of base64-char.

Hmm.  I'd missed the extraneous reference to RFC4474 here.  It should be 
removed.

 >      That's true. There was a relatively lengthy
 > exchange on the list about the need for increased specificity (and
 > examples) of exactly what component of the PASSporT object goes into
 > the signed-identity-digest. So this was on our hit list to fix here
 > already. But just because you weren't the first one to be right about
 > this doesn't mean that it isn't a valid point that we need to fix.
 > You are quite correct that "Specific reference to a specific value
 > that can be interoperably generated is needed."

 >      Of course, this
 > interrupts a sentence, and the remainder of the sentence reads, "the
 > first PASSporT object contains header information, and the second
 > contains claims, following the conventions of JWT [RFC7519]." Have I
 > mentioned that the questions that might occur to us about the first
 > few words of a sentence are often resolved by the remainder of it?

You have.  It's a shame that such mentions were mostly wrong, by my 
original and continued reading of the text...

There is nothing in the draft text that specifies in clear and simple 
terms what or where this 'first' object is, nor the 'second'.

 > After reading the rest of the sentence, the review then continues,
 > "I've gone back and looked at the Passport references to "object" and
 > do not see any clear indication that there are two, in the style
 > being summarized here." Obviously, "object" is the "O" in "JSON," and
 > indeed the JWT specification refers (for example) in Section 3 to how
 > "JWTs represent a set of claims as a JSON object", which is combined
 > with a JOSE header (a separate JSON object, as 3.1 makes clear by
 > referring to it as "the JSON object above") - in other words, one
 > might say they are two objects.

How the heck is the reader to have guessed all this, nevermind be sure 
that that their guess was correct?

 > > While the review objects that "I've gone back and looked at the
 > Passport references to 'object'", what the spec text here says is
 > "following the conventions of JWT [RFC7519]," not PASSporT. The

JWT is inherited through Passport.  It has no life in this specification 
except through passport.  Or at least, it's not supposed to.

 > reviewer would have found the answer to this question by actually
 > looking where the text suggested, but the reviewer seems defiant
 > about looking there: "I naturally assume that some portion of this is
 > inherited from JSON and/or JWT, which is a nice example of the
 > significant, additional overhead being being introduced with their
 > use. And in this case, apparently confusion." There is no need to
 > make any assumption here, the spec actually instructed you to refer
 > to JWT. The notion that there is anything to be confused about here
 > is a bunch of smoke and mirrors. [$]

And of course, a series of indirections through multiple specifications 
is no risk of confusing any other reader, except one who is defiant, in 
spite of their explicitly iting efforts to follow those pointers, 
including the ones being noted in the reply, as noted just a bit further 
in the review comments...

>> "object".  Nor does the next section, 3.2.  Yet, apparently, both should.

Again:  For all of the sturm und drang, the text says 'passport object' 
and the passport spec has no such terminology.

>> overhead being being introduced with their use.  And in this case,

{{ No response from Jon. }}

 > 8 When the spec tries to blurt out "the following elements message
 > MUST be placed as the" the review interjects "placed where?" If we
 > let the spec continues, it says, "placed as the values corresponding
 > to the designated JSON keys." There is no change required as a result
 > of this hasty review comment. The review then asks us to "Delete the
 > opening clause," presumably referring to the entire sentence. Why

Yeah, because 'clause' is often used when 'sentence' is what is meant?

 > this sentence could possibly be a source of confusion or harm to the
 > reader is absolutely beyond me. [$]

(context-setting retained.)

(is anyone else as amused as I am by the idea that anyone would suggest 
that anything about my review process was 'hasty'?)

I'm really sorry it's beyond the editor, but:

    "the following elements message MUST be placed as the values 
corresponding to the designated JSON keys:"

does not make any obvious sense to me, and lacks clear specification 
information for resolving what is being referenced.

 >      It is true, this is effectively reiterating
 > the guidance of stir-passport. I don't however think this introduces
 > any practical problem.

sigh.

 > 8 Once again the review here is concerned about "another algorithm
 > needing to be specified as an algorithm"," where "all of these 'must'
 > formations are overkill. Normally, algorithms are specified in a
 > simple, declarative manner." I don't believe the division of an
 > operation into steps containing normative MUSTs is an outlier in IETF
 > specifications.

(Again, Jon's context-setting retained, since the response cover's 
multiple of my review comments.)

 >      Given that it is an example of a header
 > object containing the three mandatory JSON keys with values that were
 > just described in the algorithm above, the reader would presumably
 > know what this is an example of by virtue of having just read the
 > words directly above it in the specification. The example is an
 > example of how the PASSporT header object would look. It
 > demonstrates... how the PASSporT header object would look. What is
 > this review comment asking? How is the target of the review to know?
 > Who could possibly think asking this question is a meaningful
 > contribution to our standards process and that it requires the
 > attention of the document authors or the working group?

oh.  so the goal is merely to show the reader what the appearance will 
be?  no concern for maybe, you know, explaining the substance of the 
example?

 >      Actually the "detail"
 > here consists of one sentence about telephone numbers and one about
 > URIs, the former of which contains a pointer to the telephone number
 > section (7.2) and the latter of which contains a pointer to the URI
 > section (7.4). There is no organizational or redundancy problem
 > here.

 >      If we were feeling generous, we might read the original text
 > as "for more information, information on the security properties of
 > these SIP message elements." I see no serious risk of this confusing

Because readers won't see 'more' and think that it normally is a 
connector to related, /preceding/ material?

Drop the 'more', and the sentence is fine.

 > readers and implementers. The review continues that "And since every
 > RFC contains a security considerations section, a generic reference
 > like this, here, is of no obvious value. It's just more text." The
 > fact that the Security Considerations contains specific analysis that
 > takes each of these SIP message fields and notes their security
 > properties is why they warrant a mention here - as the spec says,
 > when it notes that the section answers "why their inclusion mitigates
 > replay attacks" for example. Reviews that ignore what the text
 > actually says and instead critique a generic strawman are unlikely to
 > contribute much value.

whereas comments like the above are the hallmark of professionalism.

>> generic reference like this, here, is of no obvious value.  It's just

{{ No response from Jon. }}

 >      In this case, it is to the statement
 > that future extensions to PASSporT might alter the security
 > properties provided by the signature by covering new information.
 > This is a useful thing to note in this case, and no change should be
 > made as a result of this review comment.

Future extensions could do all sorts of things.  The statement here does 
not affect implementation of the current spec or use of the current spec.

 >      The answer is no, there isn't
 > something that appears to constrain the choices, but implementers
 > might be tempted to think that a call to a telephone number always
 > comes from a telephone number or vice versa, and thus create code
 > that would not accommodate the heterogeneous case.

The specification of orig and dest might warrant a comment highlighting 
the opportunity for variety.  A document discussing implementation and 
use might warrant some similar commentary.  But there is not compelling 
reason for having the commentary here.

 >      Indeed, Section 3.3 just
 > defers to JWS, as the part that reads "as specified by JWS" should
 > indicate. So stir-passport just passes the buck - but surely that's
 > what stir-passport should do, albeit it should do so with a bit more
 > precision. I won't disagree that this could be beefed up in
 > stir-passport, but I think rfc4474bis should defer to the
 > stir-passport text.

Because two levels of indirection always helps reader comprehension.

And the text here refers to hashing, not signing, which is what the 
passport section says it is about...

>>> "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo

 >      We plan to have a separate spec to
 > do that, actually.

 > 8 Exactly how radical the "departure from JWT practice" at the end of
 > Section 8 was a recent subject of working group discussion, in light
 > of varying interpretations of the JWS RFC (especially Appendix F on
 > "Detatched Content"). Here the review is of course correct when it
 > points out the unlikelihood that "JWT normally calls for including
 > the encoded version of JSON objects in the Identity header (field)?"
 > Our interpretation of JWT and JWS was much of what we discussed at
 > the last meeting, and we expect that stir-passport will be crisper on
 > this point. There may be some rfc4474bis text that falls out from
 > that, we'll see.

>>>    [I-D.ietf-stir-passport] Section 4.

{{ No response from Jon. }}

 >      the beginning of
 > Section 9 gamely notes that the extensibility of PASSporT object is
 > covered in Section 4 of stir-passport. The benefit of having this
 > directive is that it directs you to the place where extensibility of
 > PASSporT objects is covered.

So the idea motivating the text here is that a reader having a question 
about extensibility of passport won't naturally think of looking at the 
passport spec?

>> Perhaps this is meant to refer to that doc's section 4.1 header parameter?

{{ No response from Jon. }}

 >      the latter presumably is asking why have "ppt"
 > as a parameter of Identity rather than just reading it from the JOSE
 > header of the PASSporT object. The answer to the second is that it is
 > necessary for verification services, as in the absence of "canon,"
 > that is the only indication present that an extension is in use (and
 > "canon", per the last paragraph here, is required only if the new
 > claims cover elements not in the SIP request). Even when "canon" does
 > appear, it is also a nice processing optimization, as the verifier
 > only needs to read this parameter to know whether or not the header
 > is supported, it doesn't have to crack the object open. To the first
 > question: yes, we are currently thinking that each Identity header
 > will contain a PASSporT object with at most one extension. This is
 > mostly to keep it simple here at the start. We have played around
 > with a few alternative models, but this is the one that stuck.

The text here contains normative language about ppt here, rather than 
where ppt is specified.

Neither of the already-asked questions were answered.  The 'presumably' 
interpretation is incorrect.  The point behind the second question is 
that I had not understand that ppt is a way of invoking a pre-registered 
configuration profile for STIR (or is it for Passport)?

I also don't see an IANA registered section for the needed ppt registry.

 >      This calls out a block of informative text in
 > a section dedicated to extensibility, that, although reflected in the
 > normative behavior of the authentication and verification services in
 > Section 5, nonetheless merits a reminder.

>>   If...but then  appears to be a non-sequitor or incompletely formulated
>> sentence.

{{ No response from Jon. }}

 >      It is a bit hard
 > to see that argument in light of the fact that the Identity header,
 > the associated response codes, the concepts of the authentication and
 > verification service, and many other related elements were present in
 > RFC4474.

Consider efficacy.  No one benefits from the discussion of the previous 
document, because it has no installed operational base.

>> an entirely new document and not a bis.

{{ No response from Jon. }}

 >      I think it has a
 > common meaning of being a strong identification of the originator.
 > This isn't a term of art.

Correct.  But while a word like 'strong' is likely to evokes useful 
marketing emotion, it is unlikely to have a technical meaning that is 
clear and consistent across readers.  This being a specification rather 
than a sales brochure, such effects should be concerning.

 >      Perhaps by looking at the prior sentence, which refers to "the
 > standard SIP practices for privacy described in [RFC3323]". The
 > abstract of that specification indicates that it is where a "privacy
 > service" is defined. It is not a stretch to expect that an interested
 > reader would make this deduction. [$]

Except that a term like "a privacy service" surprisingly is read as 
referring to, well, you know.  A service.  A thing that provides 
service.  It does not refer to some practices within some other service.

The term is introduced without explanation and with an intuitive, and a 
denotational, meaning that is simply wrong.

 > The preceding sentence notes that a certain type of SIP intermediary,
 > a proxy server, can act as both an authentication service and a
 > privacy service. The preceding paragraph gave some indication of the
 > nature of the personal information that might be revealed by the
 > identity asserted in a SIP request, which could include "the name of
 > a human being, their place of work or service provider, and possibly
 > further details." So we've established that there is a certain
 > tension between optimizing for privacy and asserting identity. So,
 > when the current sentence explains that private SIP URIs could be
 > signed by an authentication service, it is perhaps saying something
 > counterintuitive. I'm not sure this is an important point, so much as
 > perhaps a non-obvious one. I think its import is obvious, despite the
 > reviewer's bafflement.

Having re-read the original text a few times and the response here a few 
times, I will unfortunately have to say that none of it accomplishes the 
apparent goal.  That is, I'm not understanding the issue being addressed 
nor the meaning of what is intended to address it.

Again, I'm sure no one else will suffer this comprehension failure.

 >      the review counters, perhaps questioning why
 > this text appears in a section about privacy, or how it relates to
 > privacy. It relates to privacy because it is making a statement about
 > private URIs from RFC3323.

 > 11 The review objects to the presence of "however" in a sentence that
 > will ultimately explain that you can't have a certificate associated
 > with an invalid domain name like "anonymous.invalid", which is
 > recommended for use in RFC3323. The "however" distinguishes that you
 > can't have an authentication service sign these URIs like you can
 > URIs for valid domains like "anonymous.example.com". Since the review
 > requests that we cite where "anonymous.invalid" is documented, that
 > would be RFC3323. Which is already cited here. As its last bit of
 > wordsmithing, the review finally objects to the use of "like" in the
 > construction "using domains like 'anonymous.invalid'". "how is one to
 > tell what other domains are 'like it?" Well, the important property
 > such domains would have is that they have invalid domain names,
 > presumably (though not exclusively) in the .invalid TLD. [$]

The response mostly makes the case for why the opening 'however' is 
incorrect.  The word is a connector with something said immediately 
before, not immediately after.  That is, correct:  a, however b. 
Incorrect: however b, a.

Again:  there is no established context to which the 'however' is 
responding.

-- 

        Dave Crocker

-- 

   Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Aug 2016 09:56:48 -0700

Hi Dave,

Thanks for your thorough review. I'm going to mostly let Jon handle the
first round
(as you can see, he's done most of the work on this spec so far),
especially as much
of it seems to be detailed (and valuable) but straightforward comments.

What wasn't clear to me was whether there were any major architectural or
technical concerns in your review. I'm not asking you to write an entirely
separate
review or anything, but you obviously know what you think is important
better
than I do, so would it be possible for you to perhaps highlight anything
you think
is seriously architecturally/technically wrong by cutting-and-pasting into
a separate
message, or some other recourse?

Thanks,
-Ekr

On Mon, Aug 8, 2016 at 8:46 PM, Dave Crocker <[email-masked]> wrote:

> placed the identification value into the field was authorized by its owner
> to do so.  This specifications is part of a collection of specifications
> intended to enable such validation.
>
>
> background or citation.  Many uses of 'header' are probably supposed to be
> 'header field'.  My sense is that quite a bit of terminology is used
> equally loosely.
>
> knowledge and are certainly not usable by an implementer who is not already
> deeply embedded in the community that produced these specifications.  My
> impression is that being embedded won't suffice either, both from my
> assessment of the documents' deficiencies and given back-channel comments I
> have heard about the expectation of the work to be done after these
> specifications are published.
>
>
> diligent pass by a technical editor.  I suspect this will uncover quite a
> number of semantic deficiencies in the text.
>
>
> for the specification of credentials, here.  That means that the technical
> details -- as distinct from the operational policies -- of credentials are
> out of scope, although they are fundamental to proper operation of this
> serve.  This is a showstopper, in terms of specification completeness for
> the service.
>
> How is the recipient to know what credential 'standard' is used?  How does
> this ensure interoperability between two participants who have not
> interacted before?
>
> elsewhere.  By way of example, there are few if any cross-organization key
> management services on the Internet that demonstrate the utility needed
> here.  I am pretty sure that Web certs don't qualify.  We know that DKIM's
> operation does, of course.  However DKIM strictly uses domain names as
> identifiers and they conveniently align with their administrative
> authorities, whereas telephone numbers do not...
>
>      [[[ The mailing list just had an extensive regurgitation of critical
> commentary about ENUM.  What appears to be getting missed is that whatever
> mechanism is going to be used for finding and validating keys is going to
> have no operational history of reliability, safety or efficacy. ]]]
>
> except its fireplace or its front door and calling that a remodeling. The
> previous document does not have an installed base, so I strongly suggest
> removing all references to it.  It will allow some of the text to be
> notably simpler and clearer.
>
> The document is heavy with forward references.  These force the reader to
> stop what they are in the middle of, try to hold that place, and look
> forward to understand what they've just been interrupted from reading. As a
> literary style, forward references create useful tension.  In
> reorganization so that integrative text comes /after/ the text describing
> the pieces being integrated.  And opening overview, design summary, or the
> like can give a non-normative description of the architecture and the
> service, so the reader has a basic sense of the big picture, before diving
> into the detail of those to-be-integrated pieces.
>
>
>
>
> Detail Comments
> ---------------
>
> Abstract
>>
> 'cryptographically' is not the issue here  That is, it is a means, not an
> end.
>
>
> 'interdomain' might suffice, but I suspect it's worth pressing the issue,
> with language like "especially across trust boundaries" or somesuch.
>
>
> one.  If the claim is actual enhancement, then what mechanism is enhanced
> and how does authenticating origin constitute enhancement of it?  My point
> is that I believe the existing mechanisms will operate the same in the
> future as they have been.  This spec doesn't change them.
>
> the document.  If the current spec is successful, history like this will be
> distracting, 10 years from now....
>
>
> 2.  Terminology
>>
> summary description of the mechanism being defined here.  I suggest having
> this section only give background on sip and the problem, with a separate
> section for the design summary.  Or else call this Introduction, but really
> it would be better to split them.
>
>
>
> Note that the preceding discussion makes no mention of "SIP URI".  If one
> reads back and connects some dots, the reader might guess that the alice@
> discussion is for a SIP URI, but the text should make this explicit.
>
> needs to be quite a bit sooner, since it is fundamental.  Certainly it is
> not 'background'.
>
>
> the verifying side.  How is the reader to know for certain?  A diagram of
> the overall service and its components could be quite helpful.
>
>
> And it might not.  To the extent that you have to say something about work
> that might or might not be done, just cite the topic and that it isn't
> covered here.  Such as:
>
> (Odd thought:  Given that JSON isn't native to SIP and that there must be
> some translation/encoding of the json object to work with SIP, that
> "To maximize end-to-end security, it is obviously preferable for end-users
> to acquire their own credentials;?
>
> I'm not exactly sure what this means or is supposed to mean, but I suspect
> it's incorrect.
>
>
> such as use of a proxy, which might not apply in some valid scenarios. As
> some integrative pedagogy, that's fine.  So I suggest re=labeling the
> work.  It reduces to:  something will get authenticated, but we won't say
> what and we won't say where to find out.
>
>
> motivated nor explained usually proves more of a distraction than a help,
> when writing an 'overview' or an example.
>
>
>
>>
>>
> A scheme that has an untrusted object carrying information about where to
> find trust information for the object sounds like a serious security hole.
> Why should the pointer be trusted?
>
>
> Huge operational transition question:  How is the absence of the signature
> treated?  Today, there are no signatures.  Tomorrow there might be some,
> both it won't be true that /all/ incoming requests are signed.  So how is
> the receiver supposed to handle the absence of a signature?
>
> /never/ break the signature?  What is the basis for that assessment? And if
> a signature /can/ break, then the interpretation of an invalid signature
> could mean either spoofing or operational error.
>
>
>
> Constant references to implementation (and 'instantiation') possibilities
> distracts from the required task of defining the architecture and functions
> of the service.
>
>
> Also, this requirement for authentication appears to be redundant with the
> later specification for authentication in Step 2.
>
>
> The "the procedures" sentence adds nothing and is redundant with the later
> "entities instantiating" sentence.
>
> relevant details, so that there already is context and this just enhances
> it.
>
>          The authentication service performs the following steps in order,
> to...
>
> this isn't as easily grokked.  That invites both writing and reading errors
> to the algorithm.
>
>
>    Step 1:
>>
>
>
> intermediary?  Although the word is used frequently in the SIP spec, it is
> not defined.
>
>
> Remove the pedagogy after the first sentence.  The choices are outside of
> this specification and the spec is not enhanced by pedagogy about technical
> matters outside of its scope.
>
> 'checking' and 'converting' are very different actions.  So 'it does not'
> does not flow from the preceding text in the sentence.
>
>
>
>>    Step 3:
>>
>
>         Step 3:  Timestamp
>
>
>
> Why?  (Probably only need to cite the earlier discussion about its use for
> replay mitigation. But merely cite; don't duplicate.)
>
>
> definition of its roles implies that it doesn't, but rather that it is part
> of one or another module that does.
>
>
> and hence it doesn't do retries.  All of this needs to be recast in terms
> that match the specified architecture.
>
>
> [optional] remove.  Especially given the MUST.  It doesn't matter whether
> the ppt was optional for the signer.
>
> as long as the ppt is "supported".  That is, an absent ppt and a valid ppt
> both produce the same sequence 'below'.
>
>
>
>>    Step 2:
>>
>
>        Step 2:  Signature Scope
>
>
> There was earlier discussion of using a date window validation to mitigate
> against some attacks.  There doesn't need to be yet-another reference
> here.  Just cite the earlier discussion.
>
>
> different methods of doing signature validation, depending upon whether ppt
> is present.  This seems like an outstandingly bad idea.  It creates
> There needs to be a single algorithm for validation, even if components of
> the algorithm have branches, such as depending on whether the 'address' is
> a URI or a telephone number.
>
>
>
> environment is expected and required to convey Identity fields perfectly,
> all the time.
>
>
> I suspect the above paragraph belongs elsewhere and sooner.  It isn't part
> of the step sequence.
>
>
>
> has been established elsewhere.  The task here is merely to specify what is
> in a canon.
>
>
> This appears to be a re-specification of canon.  Don't do that.  Cite its
> spec and then simply use it.
>
>
> The implication is that "a set of domains" is not "an entire domain", but
> I don't understand how the language says that.  As written, this actually
> translates to something like: authority over one or more domains.  Possibly
> what was meant is something like:  authority over an entire domain, or some
> number of sub-domains under that higher-level domain.
>
>
>       Similarly for telephone numbers, a credential can represent one or a
> range of numbers.
>
>
> So, there is no standard for the specification of credentials, here. That
> means that the technical details -- as distinct from the operational
> policies -- of credentials are out of scope, although they are fundamental
> to proper operation of this serve.  This is a showstopper, in terms of
> matter for local policy, the specification should not then go on to specify
> examples of local policy.  In those cases where there is a compelling
> benefit to include such examples, put them in an appendix. But please,
> then, explain that compelling benefit.
>
>
> where the object giving a pointer to its own credential.  Or rather, I fear
> that I do understand it, but don't understand why its considered credible.
>
>
> public specification.  A complete specification of a STIR service needs to
> include a publicly-usable key certification mechanism, a la DANE or DKIM or
> the like.
>
> The application of STIR for other, non-open operations are always free to
> amend the specification through a separate profile that overrides one or
> another piece of the base STIR specifications.
>
>
>
> that the document is specifying a validation service that does not provide
> a deterministic means for assessing validation.
>
>
> If there is a compelling desire to give implementation advice, move it to
> a separate document and make it more complete.
>
> references to the Identity-Info header field, but assume that's not what is
> meant here.
>
> I also find abnf for an ident-info rule, which includes an "ident" literal
> string.  I suspect this is the reference you intend?
>
> Please reference these more formally and properly cite their definition at
> first use.  (If you want to rename rules, to make the use of the rulename
> more pleasant in the text, that's fine.  But just make sure that a new
> reader can understand what type of reference is being made and where to go
> to find its definition.
>
> Ditto for "alg".
>
> Ditto for ppt.
>
> Again, specification, not handling.  Also, what do the instructions mean?
> How is the signer to know what is dereferenceable by the verifier?
>
>
> authorized credentialing services and then refer to the one that is used by
> name.  That provides independent vetting and limits the 'vocabulary' of
> credential service references the message can cite.
>
>
> section and simply state that the details of the credentialing system are
> outside the scope of this specification, except for specifying a registry
> that lists possible systems.
>
> Also note that the claimed interest in authentication beyond SIP will also
> require credentialing systems.  As such, the entire topic appears to be
> larger than this specification.
>
>
> not appropriate for inclusion inside a technical specification.  Move it to
> a separate document.
>
>
> understand this.  The signing algorithms are for the payload using the key
> /from/ the credential.  So what does this requirement mean, and why?
>
>
>
> supported within a scope sufficient to include the authentication service,
> the verifying service and the credentialing service.
>
>
>
> Focuses primarily?  What I've been reading in this spec covers both phone
> and uri forms.  So I don't know what the 'primarily' refers to.
>
>
>      Local policies might choose to use a value from fields other than To
> and From.  The details for this are outside the scope of this specification.
>
> If there is an algorithm to follow, specify it as an algorithm. Otherwise,
> this is non-normative discussion and isn't very helpful here.
>
>
> deterministic specification, with what incremental value can be obtained by
> the addition of some non-normative heuristics.  Separate these and make the
> deterministic stuff part of the specification and the heuristics part of an
> external document discussing real-world implementation, or somesuch.
>
>
>
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Aug 2016 07:31:39 +0000

I did read through this review of my responses, or a re-review we'll call
it. Although it does appear that I neglected to respond to some comments
in the initial review, I don't think they turned out to be very major
ones. I did try at the end to singe out the points that the re-review
considers with special emphasis; but again, I'm not sure I see these as
showstoppers.

Tha much said, I hae been making numerous changs in going through the
spec after readig this and some other detailed reviews I've received, so
I'm sure ths is influncing the changes being made, even were my initial
reaction here is to push back.

Jon Peterson
Neustar, Inc

On 8/19/16, 2:54 PM, "stir on behalf of Dave Crocker"
<stir-bounces@ietforg on behalf of [email-masked]> wrote:

>     > Jon' responses into
>to elminate that burden.  I'll apologize now, for the inevitable
>miscorrelations that are sure to hav occurrd.  Also, I'd advised Jon
>that skipping the small stuff would be fine, ut he seems not to have
>(In a meager effort to abbreviate things however slightly, I've deleted
>so many more clever choices.  But my favorite was "interject with
>I've put "{{ No resonse from Jon. }}" as needed.  Again, for the minor
>stuff, in a nomal review discussion, I wouldn't worry about such
>omissions. Alas, given the relities of this particular exchange, it
>seems worth marking things explctly for the record.
>
>I'm also sorry that I think it necessary to inludeall of the original
>material.  Again, in a normal exchange I'd elide asmuch as possible,
>> On 8/8/016 8:46 PM, Dave Crocker wrote:
>>> eview of:  Authenticated Identity Management in the Session Initiation
>>>            Protocol (SIP)
>>> ID:         draft-ietf-stir-rfc4474bis-0.txt
>>> Date:       8 August 2016
>>> ready for pblication.
>>> Terminology is used inconsistently. It ofte is introduced with no
>>> be 'eader field'.  My sens is that quite a bit of terminology is used
>>> equally loosely.
>>>
>>> ogether.  In fact is appears that the document itself gets confused on
>>> this matter.>>>
>>> Algorithms are all offered only as prose and often in a form itigating
>>> comprehension, such as tendig towards negation or disjunctin, which
>>> can tell, the algorithms often ae incomplete, but serious analyisis
>>> difficult.
>>>
>>> The documents appear t rely on a reader's having quite a bit of prior
>>> already deeply embedded n the community that produced these
>>> either, both from my assessment of the documnts' deficiencies and
>>>given
>>> be doe after these specificatons are published.
>>>
>>>
>>> Overall, the writig impedes comprehension and the documentneeds a
>>>very
>>> diligent pass by a technical editor.  I suspect this will uncover quit
>>> There is a possibl tendency to support more alternative behavior than
>>> appropriate. Successul ineroperaility usually benefits from fewer
>>> choices, not more.  Common, mandatory cannicalization is an example.
>>>
>>> Credentials: the specification neiher definesnor references a
>>>standard
>>> for the specification of credentials,here.  That means that the
>>> credentials are out of scope, although they are fudamental to proper
>>> specification cmpleteness for the service.
>>>
>>> t base, these specifications appear intended to roughly chart out a
>>> system structure, leaving most of the diffcult work for later and
>>> elsewhere.  By way of example, there are few if any cross-orgnization
>>> neede here.  I am pretty sure that Web certs don't qualify.  We know
>>> domain names as identifiers and they onveniently align with their
>>> administrative authorities, whereas telephone numbersdo ot...
>>
>>> There is remarkably little f the oiginal RFC 4474 substance still in
>>> The previous document does not ave an installed base, so I strongly
>>> suggest removing all references to it.  It wil allow some of the text
>>> architecture and the service, so the readr has a basic sense of the
>>>big
>>> 'cryptographically' s not the issue here  That is, it is a means, not
>>> an end.
>
> >The very first interjection in theline-by-line review rejects the
>> assertion in the Abstract that the ecurity mechanisms of SIP are
> > "inadequate for cryptographically ssuring the identiy of end
> > users," instead arguing that we shold substitute "adquately" for
> > "cryptographically". This would however result intext that reads
> > "nadequate for adequately assuring the identity of end users." I
> > think "inadequate for dequately" is a poor change. This is a pretty
> > line-by-line comments often cosider only one atom of the spec in
> > isolation from its surrounding context and thus pose difficulties
>And while ye, I didn't catch the redundant vocabulary, you seem to have
>missed my pint entirely.  So I'll say it more fully:
>
>         Overview text, for nything that is not defining new>cryptography, but which starts by citing cryptography, is usually
>faling to focus on wha is primary:  necessary goals and functionality,
>which are the why and what, and is instead bein distracted by the
>hould not be citing crypto but sould, for example, authentication.
>
>Cryptography and theuse of cryptography are not a primary goal and so
>>>>    interdomain conext.  This document defines a mechanism for
>>>>securely
>>>
>>> 'terdomain' might suffice, but I suspect it's worth pressing the
>>> issue with language like "especially acrosstrust boundaries" or
>>>somesuch.
>
>{{ No response fm Jon. }}
>
>
>>>
>>>>    This document provides enhancements t the existing mechanisms for
>>>>    authenticated identity management in the Session Initation
>>>>Protocol
>>>>    (SIP, [RFC3261]).  An identity, for the purposes of this documen,
>>>>is
>>> ne.  If the claim is actual enhancement, then what mechanism is
>>> enhaced and how does authenticating rigin constitute enhancement of
>>> it?  My point is that I believethe existing mechanisms will operate
>>>the
>>> same in the future as hey have been.  This spec doesnt change them.
>>>
>>> Mve definitions toan explicit terminology section, rather than
>>>putting
>>> diffeetly than elsewhere than SIP???  Then why is 'for the purposes
>>>of
>>> his document' included?
>
> >      At a high level, I
> > verification service - I kind of think it's overkill.Also, all three
>definition easy.  As for whether there ar only 3 terms in the document
>that need to be explicitly defined,I didn't do an audit, but I believe
>>>>    [RFC3261] spcifies several places within a SIP request where users
>>>>    can express an identity for hemselves, most prominently the user-
>>>>    autentication mechanism.  This leaves SIP vulnerable to a category
>>>>    lessspoofable assurance of identity thn the Caller ID services
>>>>that
>>>>    the telephone network provdes today.
>>>>
>>>>    support other security schemes as well).  Howeve, few SIP user
>>>>    agents today support the end-user certificates ecessary to
>>>>    authenticate themseves (via S/MIME, for example) and for its part
>>>>    Digst authentication is limited by the fac that the originator
>>>>and
>>>>    As n initial attempt to address this gap, [RFC4474] specified a
>>>>    mean of signing portions of SIP requests in order to provide an
>>>>    identty assurance.  However, RFC 4474 was in several ways
>>>>misaligned
>>>>    with deployment realities (see
>>>>I-D.rosenberg-sip-rfc4474-concerns]).
>>>>    Most significantly, RFC 4474 id notdeal well with telephone
>>>>numbers
>>>>    as identifiers, despite thei enduring use in SIP deployments.  RFC
>>>> Peterson, et al.         Epires January 8, 2017                [Page
>>>>3]
>>>>
>>>>
>>>>    signature format with PASSporT [I-D.ietf-tir-passport].
>>>
> >     [I]t belongs where it does becuse this is an
>To the extent hat historical narrative is necessary -- which it is not,
>in this cae, given the lack of any installed base that cares about the
>history - that should go into a separate section that can be ignored by
>developrs.  When historical narrative does have relevance, it needs to
>be qute brief; when it isn't, the text is a distraction.
>
>
>>>> 2.  Terminlogy
>>>>
>>>>   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "REOMMENDED", "NOT
>>>>    RECOMMENDED", "MAY", and "OPTIONAL" are to be nterpreted as
>>> This ection includes far more than background.  It also provides a
>>> summary descripton of the mechanism being defined here.  I suggest
>>> having this section only give background on sp and the problem, with a
>>> separate section for the designsummary.  r else call this
>>> Introduction, but really it would be better to split hem
>
> >      While I
> > isn't a change I'd rule out. I don't se any great urgency to do it,
> > either.
>
>Yeah.  Clearer organization, designed to faciliate initial reading and
>>>>    swatting are enabled by an attacker's ability to impersonate
>>>>omeone
>>>>    of the former would be a voicemail service that compares the
>>>>identiy
>>>>    calling party number (and/or Caller-ID) of a caler, which a human
>>>>    both of these cases, attackers might attempt o circumvent these
>>>>    mechanism described in this document proides a strong identity
>>> many things, whereas the goal her is quite specific.
>>>
>>> So replace it with:
>>>
>>> It likely will validate them in multiple places, including icoming
>>> requests.
>
> >    As described in his
> > specification, an uthentication will not do that.
>

>Worse, from various postings over thelast few weeks, it's clear that
>>>>    agent or as a proxy server; typically, it is a component of a>>>>network
>>> opertor?  the term is ambiguous.
>
>>>>    cryptographic information (including a digitl signature over some
>>>>    of a particular identity has beenauthorized.  A "veriication
>>>>    service" on the receiving end then validates this signaure and
>>>>    enables policy decisions to emade based on the results ofthe
>>>>    verification.
>>>>
>>>>
>>>>
>>>>
>>>> Peterson, e al.         Expires January 8, 2017                [Page
>>>>4]
>>>>
>>>>
>>>> Internet-Draft                SIP Identity                     July>>>>2016
>>>>
>>>>
>>>>    Identities are issued to users by authorities.  When a nw user
>>>>    service for that domain can issue them an identity in hat
>>>>namespace,
>>>>    such as [email-masked].  Alce may then send REGISTER requests
>>>>to
>>>>    But ultimately, it s the controller of the SIP service at
>>>>    example.com that must be responsiblefor authorizing the use f
>>>>names
>>>>    SIP, the credentials needed  prove a user is athorized to use a
>>>>   owner: ether a user agent gives requests to the domain name ownr
>>>>in
>>>>    order for them to e signed by the domain owner's credentials, or
>>>>the
>>>>    the domain owner has given the user agent the rght to a name.
>>>>
>>>>    The situation is however more complicated for telephoe numbrs,
>>>>    however.  Authority over telephone numbers does ot correspond
>>>
>>>          however...however
>

>
>>>
>>>>    directly to Internet domains.  While a user could regiter at a SIP
>>>>    connection between te administrator of that domin and the
>>>>    assignment of telephonenumbers isnot currently reflected on the
>>>>    nternet.  Telephone numbers do not share the domai-scope property
>>>>    described above, as they are dialed without any dmain component.
>>>>    This document thus assumes the existence of a seprate means of
>>>>    telepone numberis the identity of the user.  As with SIP URIs,
>>>>the
>>>    either in the endpoint or t some intermediary.
>>>
>>> Note that the preceding discussion makes no mentionof "SIP URI".  If
> > actualy the text says:
> > becomes associated with example.com, the admnistrator of the SIP
>>>>    This doument specifies a means of sharing a cryptographic
>>>>assurance
>>>>    of end-user SIP identityin an interdomain or intradomain context.
>>>
>>> I suspect the above sentnce is seriously redundant.  If it isn't, it
>>> needs to be quite a bit soner, since it is fundamental.  Certainly it
>>> is not 'background'.
>
> > hard to see how much sooner in the specification statements canbe
> > made than here.
>
>A statement of the purpose of a document sould come sooner than Section
>3.
>
>
>>>>    It relies on the authenticaton service constructing tokens based
>>>>on
>>>>    request.  The authentication service then computes a signature over>>>>    those JSON object in a manner following PASSporT.  That signature
>>>>is
>>>
>>> "those JSON object" ?
>>>
>>> Also, where is the object?  How is it creaed? How is it conveyed?
>
> >      This is
> > operations. This review is very critical of forward references and
> > to becommunicated in some order. Giving a big picture up front
> > without suc details is helpful.
>
>work.  Yet this references ext is about the *technical substance of
>this document*.  Tat's 'fore'ground.
>
>
>>> Also 'The authentication service' might referto the signing side or t
> > described here behaves differently, and doesnot appear on the
> > might be played by elements in different components of a callflow,
> > comlete picture.
>this o that, here or there.
>
>
>>>>    then placed in a SIP Identity heade.  In order to assist in the
>>>
>>>         header /field/?
>
> > review mentions this. There's another in 5. ("header? or header
> >field?"), some in 5.2 ("headers? header fields?" and a few hints of>  "header [field"), at the beginning of Section 8 ("header *field*")
> > nd so on. Tobe clear, the review is absolutely correct that there
> > requess that do not have one.  The authentiction service MUST
> > ensure that any preexisting Dte header in the request is accurate.
> > "header field value" in rfc4474bis, it ooks like "header" appears
> > around 240 times, and "header field" only a fw more than 70. Surely
> > diligent we were in trying to keep thse straight. But if you look at
> > subsequent header specifications for SIP, lik say Replaces (RFC3891)
> > well, because as that quote above from 5.1 illustrate, there isn't
> > any damaging ambiguity about this. The second sentence reallyis
>I'm not sure wat the point of a lengthy history about other
>inconsistent uses of the terms is, unless thy are supposed to somehow
>Really, I wa making only the simplest of points:  These terms have
>cite definitions of terms ofart and it should use them carefully and
>correctly.
>
>
>>>>    Note that the scpe of this document is limited to providing this
>>>>    identity assurane for SIP requests; solving this problem for SIP
>>>>    work might specify ways that a SIP implementation could gateway>>>>    PASSporT objects to other protocols.
>>>
>>> And it might not.  To the extet that you have to say something about
>>> isn't covered hre.  Such as:
> >>
> > clear from a casual glance at the RFC series that tatements about
>that the very large body of problmatic RFC content serves as precedent
>Forgive me for taking the view that the goal should be writingRFCs well
>nd noting that RFCs that are clear about the boundaries of the spec --
>including explicitly noting items tha are outside of scope -- tend to
>and the fact of the matter is that anything oher than trivial
>>>processing,
>>>or
>>>formulated

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Aug 2016 07:32:15 +0000

Okay, okay, we will endeavor to improve the "header" terminology here.

Jon Peterson
Neustar, Inc.

On 8/19/16, 9:13 AM, "stir on behalf of Paul Kyzivat"
<[email-masked] on behalf of [email-masked]> wrote:

>>>From my experience as GenART reviewer, I can say that usage of
>>>consistent >terminology is something that the whole IETF suffers from.
>>>But, it¹s getting better :)
>>