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

["Peterson, Jon" <[e-mail]>]

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 [e-mail]> wrote:

>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' responses into
>
>      >> my original review note,
>
>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
>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 "interject with
>bafflement"; that was really creative.)
>
>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,
>but am afraid it would be risky here.
>
>
>
>
>> 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
>>> Reviewer:   D. Crocker <[e-mail]>
>>>
>>>
>>>
>>>
>>> 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 pblication.
>>>
>>>
>>>
>>> Terminology is used inconsistently. It ofte is introduced with no
>>> background or citation.  Many uses of 'header' are probably supposed to
>>> be 'eader field'.  My sens 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
>>> 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
>>> humans process less well than affirmatives and conjunctions. From what
>>>I
>>> 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
>>> knowledge and are certainly not usable by an implementer who is not
>>> already deeply embedded n the community that produced these
>>> specifications.  My impression is that being embedded won't suffice
>>> either, both from my assessment of the documnts' deficiencies and
>>>given
>>> back-channel comments I have heard about the expectation of the work to
>>> 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
>>> a number of semantic deficiencies in the text.
>>>
>>>
>>> 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
>>> technical details -- as distinct from the operational policies -- of
>>> credentials are out of scope, although they are fudamental to proper
>>> operation of this serve.  This is a showstopper, in terms of
>>> specification cmpleteness 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?
>>>
>>> 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
>>> key management services on the Internet that demonstrate the utility
>>> neede 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 onveniently align with their
>>> administrative authorities, whereas telephone numbersdo ot...
>>
>>>      [[[ 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 f the oiginal 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 ave an installed base, so I strongly
>>> suggest removing all references to it.  It wil 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 readr has a basic sense of the
>>>big
>>> picture, before diving into the detail of those to-be-integrated
>>>pieces.
>
>{{ No response from Jon. }}
>
>
>
>>> 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' 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
> > good indication of the major limitation of the review overall - these
> > line-by-line comments often cosider 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 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
>underlying mechanics, which are the how.  In this case, that means it
>hould not be citing crypto but sould, for example, authentication.
>
>Cryptography and theuse of cryptography are not a primary goal and so
>the summary text should instead focus on the primary goals.
>
>
>>>
>>>
>>>>    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. }}
>
>
>>>
>>>>    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 t the existing mechanisms for
>>>>    authenticated identity management in the Session Initation
>>>>Protocol
>>>>    (SIP, [RFC3261]).  An identity, for the purposes of this documen,
>>>>is
>>>>    defined as either a SIP URI, commonly a canonical address-of-record
>>>>    (AoR) employed to reach a user (such as
>>>>    'sip:[e-mail]'), 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
>>> 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
>>> them into an Introduction.  Also, does this document use the term
>>> diffeetly than elsewhere than SIP???  Then why is 'for the purposes
>>>of
>>> his document' included?
>
> >      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 ar 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.
>
>
>>>
>>>>    [RFC3261] spcifies several places within a SIP request where users
>>>>    can express an identity for hemselves, 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
>>>>    autentication 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
>>>>    lessspoofable assurance of identity thn the Caller ID services
>>>>that
>>>>    the telephone network provdes 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).  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
>>>>    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 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
>>>>    4474 also provided a signature over material that intermediaries in
>>>>    existing deployments commonly altered.  This specification
>>>>therefore
>>>>
>>>>
>>>>
>>>> Peterson, et al.         Epires 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-tir-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....
>
> >     [I]t belongs where it does becuse 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 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
>>>>
>>>>    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
>>>>   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "REOMMENDED", "NOT
>>>>    RECOMMENDED", "MAY", and "OPTIONAL" are to be nterpreted as
>>>>    described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919].
>>>>
>>>> 3.  Background
>>>
>>> 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
> > 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 se any great urgency to do it,
> > either.
>
>Yeah.  Clearer organization, designed to faciliate initial reading and
>later consultation, probably isn't all that helpful.
>
>
>>>>    Per [RFC7340], problems such as robocalling, voicemail hacking, and
>>>>    swatting are enabled by an attacker's ability to impersonate
>>>>omeone
>>>>    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
>>>>identiy
>>>>    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 caler, which a human
>>>>    may review to make a policy decision before answering a call.  In
>>>>    both of these cases, attackers might attempt o 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.
>
>{{ No response from Jon. }}
>
>
>>>>    mechanism described in this document proides 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 her is quite specific.
>>>
>>> So replace it with:
>>>
>>>           ...enables an authentication capability for protecting
>>>against...
>
>{{ No response from Jon. }}
>
>
>
>>>
>>>>    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 icoming
>>> requests.
>
> >    As described in his
> > specification, an uthentication 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 thelast few weeks, it's clear that
>different people have a different sense of what the purported
>architecture is.
>
>
>>>>    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
>>> opertor?  the term is ambiguous.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    cryptographic information (including a digitl 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.
>
>{{ No response from Jon. }}
>
>
>>>>    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
>>>>    becomes associated with example.com, the administrator of the SIP
>>>>    service for that domain can issue them an identity in hat
>>>>namespace,
>>>>    such as [e-mail].  Alce may then send REGISTER requests
>>>>to
>>>>    example.com that make her user agents eligible to receive requests
>>>>    for sip:[e-mail].  In some cases, Alice may be the owner
>>>>of
>>>>    the domain herself, and may issue herself identities as she
>>>>chooses.
>>>>    But ultimately, it s the controller of the SIP service at
>>>>    example.com that must be responsiblefor authorizing the use f
>>>>names
>>>>    in the example.com domain.  Therefore, for the purposes of baseline
>>>>    SIP, the credentials needed  prove a user is athorized to use a
>>>>    particular From header field must ultimately derive from the domain
>>>>   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
>>>>    user agent must possess credentials that prove in some fashion that
>>>>    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
>
>{{ No response from Jon. }}

>
>>>
>>>>    directly to Internet domains.  While a user could regiter at a SIP
>>>    domain with a username that corresponds to a telephone number, any
>>>>    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
>>>>    establishing authority over telephone numbers, for cases where the
>>>>    telepone numberis 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 t some intermediary.
>>>
>>> Note that the preceding discussion makes no mentionof "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.
>
> >       But
> > actualy the text says:
> > > Identities are issued to users by authorities. When a new user
> > becomes associated with example.com, the admnistrator of the SIP
> > service for that domain can issue them an identity in that
> > namespace, such as [e-mail]. Alice may then send REGISTER
> > requests to example.com that make her user agents eligible to receive
> > requests for sip:[e-mail].
> > > ... 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 following paragraph really is the design summary for the
>>>specification:
>>>
>>>>    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'.
>
> >   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 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
>>>>    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 creaed? How is it conveyed?
>
> >      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 becommunicated in some order. Giving a big picture up front
> > without suc 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 ext is about the *technical substance of
>this document*.  Tat's 'fore'ground.
>
>
>>> Also 'The authentication service' might referto the signing side or t
>>> the verifying side.  How is the reader to know for certain?  A diagram
>>> of the overall service and its components could be quite helpful.
>
> >    No, the "authentication service" as
> > described here behaves differently, and doesnot 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 callflow,
> > so it would always be just an example instantiation rather than a
> > comlete 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 o that, here or there.
>
>
>>>>    then placed in a SIP Identity heade.  In order to assist in the
>>>
>>>         header /field/?
>
> >     This is the first of many places where the
> > 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
> > 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):
> > > An authentication service MUST add a Date header field to SIP
> > requess that do not have one.  The authentiction service MUST
> > ensure that any preexisting Dte header in the request is accurate.
> > > 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 ooks like "header" appears
> > around 240 times, and "header field" only a fw 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 thse straight. But if you look at
> > subsequent header specifications for SIP, lik 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 illustrate, there isn't
> > any damaging ambiguity about this. The second sentence reallyis
> > 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 wat the point of a lengthy history about other
>inconsistent uses of the terms is, unless thy are supposed to somehow
>make inconsistent use acceptable here.  They don't.
>
>Really, I wa making only the simplest of points:  These terms have
>definition and this document is a specification.  It should define (or
>cite definitions of terms ofart and it should use them carefully and
>correctly.
>
>
>>>>    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 scpe of this document is limited to providing this
>>>>    identity assurane 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 extet 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 hre.  Such as:
> >>
> >>         Gatewaying Passport objects to other services is outside the
> >> scope of this specification.
> >>
>      I think it is pretty
> > clear from a casual glance at the RFC series that tatements 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 problmatic RFC content serves as precedent
>to allow the continued writing of bad RFCs.
>
>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
>be the better sort of writing, as do RFCs that refrain from predicting
>the future, especially since they are almost always wrong.
>
>
>>> (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...)
>
>>      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 oher 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.)
>
>
>>>>
>>>>
>>>> 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.
>
> >    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.
>
>
>>>
>>>>    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.
>
> >       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.
>
>
>
>>>>    Imagine a case where Alice, who has the home proxy of example.com 
>>>>and
>>>>    the address-of-record sip:[e-mail], wants to communicate
>>>>    with Bob at sip:[e-mail].  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 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.
>
>
>>>>
>>>>    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?
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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:[e-mail]), 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.
>
> >      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.
>
>
>>>> 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?
>
> >      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.
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>>> 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.
>
> >      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.
>
>
>>>> 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.
>
> >      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.
>
>
>>>>    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.
>
> >       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.
>
>
>>>>    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.
>
> > 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.
>
>
>>> 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.
>
> >     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.
>
>
>>>>    Section 6.1).  Intermediaries that instantiate this role MUST be
>>>
>>> forward reference.  better to put that material before this.
>
> > 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.
>
>
>>>
>>>>    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.
>
> >  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.
>
>
>>> Also, this requirement for authentication appears to be redundant with
>>> the later specification for authentication in Step 2.
>
> > This text in the introductory paragraph states, as a prerequiste for
> > operations, "Intermediaries that instantiate this role MUST be
> > capable of authenticating one or more SIP users who can register for
> > that identity." The text in step 2 states that during operations,
> > "The authentication service MUST then determine whether or not the
> > sender of the request is authorized to claim the identity given in
> > 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.
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>>    An authentication service adds the Identity header to SIP requests.
>>>
>>> Note that we've read this before.  So I'm raising a redundancy flag.
>
> >      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...
>
>
>>>>    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?
>
>{{ No response from Jon. }}
>
>
>>> 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.
>
> >    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 end of this section.
>
>The 'recommendation for moving text was especially about the 'more than 
>one' text.
>
>
>>>>    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.
>
> >           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.*
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>>>>    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.
>
> >    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.
>
>
>>>>    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
>
> >    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...)
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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?
>
> > 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.
>
>
>>>>       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:[e-mail]'); 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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>
>>>>    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.)
>
> >    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.
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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.
>
> >    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.
>
>
>>>
>>>>    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"?
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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?
>
> >      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?...
>
>
>>>>    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?
>
>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.
>
>
>>>
>>>>    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?
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>
>>>> 5.2.  Verifier Behavior
>>>>
>>>>    This document specifies a logical role for SIP entities called a
>>>
>>> redundant detail.
>
> >    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.
>
>
>>>
>>>>    verification service, or verifier.  When a verifier receives a SIP
>>>>    message containing one or more Identity headers, it inspects the
>>>
>>> headers?  header fields?
>>>
>
>And, again, the verifier does not receive the SIP message...
>
>
>>>>    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.
>
> >      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."
>
>
>>>
>>>>    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]"?
>
> >      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?
>
>
>>> Why might there be multiple Identity header [fields]?  How might they
>>> differ?
>
> >      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).
>
>
>
>>>>    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.
>
> >  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.
>
>
>>> "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?
>
> >      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.
>
>
>>>
>>>>    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?
>
>{{ 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:
>>>
>>>        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.
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>>>
>>>>    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???
>
> > 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.)
>
>
>>>
>>>>    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?
>
> > 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.
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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.
>
> >      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...
>
>
>>> 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.
>
> >      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.
>
>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>
>>>> 5.2.1.  Handling 'canon' parameters
>>>>
>>>>    If the optional "canon" parameter of the Identity header is 
>>>>present,
>
> >      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.
>
>
>>> [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.
>
>{{ No response from Jon. }}
>
>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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.
>
> > 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.*
>
>
>>>>    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.
>
> >       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.
>
>
>>>>
>>>> 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.
>
> >      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.
>
>
>>>
>>>>    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!
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> >      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.
>
>>> 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.
>
> >      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.
>
>
>>>> 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
>
>{{ No response from Jon. }}
>
>
>>> 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.
>
> >      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, 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.
>
> >      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.
>
>
>>>
>>>>    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.
>
> >      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...
>
>
>>>
>>> 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.
>
>
> >     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.
>
>>>
>>>>    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 [e-mail] or
>>>>    sip:[e-mail].  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:[e-mail]' (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  ?
>
> >      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.
>
>
>>>
>>>>    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
>
> >      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.
>
>
>>>
>>>>    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.
>
> >       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.
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>
>>>>    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.
>
> >     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.)*
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>
>>>> 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.
>
> >      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.
>     >
>
>
>>> 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.
>
>{{ No response*S* from Jon. }}
>
>
>>> And, of course, these are more forward references.  In this case, it's
>>> giving detail about something that hasn't even been defined yet.
>
> >      I'm not aware there are any forward references in 6.3.
>
>
>>>
>>>>    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.
>
> >       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).
>
>
>>>>    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?
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> >      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.*
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>> 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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> >      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...
>
>
>>>>    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'.
>
>{{ No response from Jon. }}
>
>
>>>>
>>>>
>>>>
>>>> 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'?
>
> > 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.
>
>
>>>
>>>>       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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>>>>    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.
>
> >      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.
>
>
>>>>    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.
>
> >      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...
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>
>>>> 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?
>
> >      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?
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>>>
>>>>    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.
>
> >       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.*
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    username portion of a SIP URI (e.g.,
>>>>    'sip:[e-mail];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:[phone]').  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.
>
> >      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.  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"???
>
> > 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.
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>
>>>> 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?
>
> >      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...
>
>
>>>>    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.
>
> >      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.
>
>
> >> 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?
>
> >      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).
>
>
>>> 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?
>
>{{ No response from Jon. }}
>
>
>>>>       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.
>
> > 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.)
>
>
>>>
>>>>       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.
>
> >      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.
>
>
>>> 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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>
>>>>
>>>> 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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>
>>>>    If the result of this procedure forms a complete telephone number,
>>>
>>> What is the definition of a 'complete tn'?  Cite it.
>
> >      Um,
> > we'll fix that as "E.164", though probably the ref here is to
> > RFC3966.
>
>
>>>
>>>>    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.
>
> >   That's correct. I'm willing to ditch "and signing".
>
>
>>>
>>>>    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?
>
> >      It is significant
> > because canon helps to debug operational errors that arise from
> > canonicalization problems.
>
>
>>>>
>>>>    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.
>
> >      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...)
>
>
>>>>
>>>> 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.
>
> > 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.
>
>
>
> >> 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.
>
> > 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.
>
>
>>>>    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?
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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:[e-mail]' 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?
>
> >      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.
>
>
>>>
>>>>
>>>> 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:[e-mail]',
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>>
>>>>    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?
>
> >      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?
>
>
>>>> 7.4.  URI Normalization
>>>
>>> Canonicalization for phone numbers and Normalization for URI.  Why the
>>> difference?
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    Just as telephone numbers may undergo a number of syntactic
>>>>    transformation during transit, the same can happen to SIP and SIPS
>>>
>>>   transformation  -> transformations
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>>> 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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> >      I
> > don't believe it is more clear or helpful than the spec text as
> > written.
>
>Oh boy.
>
>
>>>
>>>
>>>> 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>
>
>{{ No response from Jon. }}
>
>
>>>
>>>>
>>>>    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?
>
> >      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.
>
>
>>>
>>>>    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.
>
> >      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.
>
>
>>>>    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.
>
> >      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.
>
>
>>>
>>>>
>>>>    For future PASSporT applications, it may be desirable to provide an
>>>>    identifier without an attached protocol scheme.  Future
>>>
>>> Discussion about future hypotheticals, again.  Remove.
>
> >      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.
>
>
>>>
>>>>    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.
>
> >      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 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.
>
> >      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.
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>> <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.
>
>{{ 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.
>
>
>>>
>>>>
>>>> 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.
>
>Hmm.  I'd missed the extraneous reference to RFC4474 here.  It should be 
>removed.
>
>
>>>>    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.
>
> >      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."
>
>>>
>>>>    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?
>
> >      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...
>
>>>
>>>>    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.
>
>Again:  For all of the sturm und drang, the text says 'passport object' 
>and the passport spec has no such terminology.
>
>
>>> 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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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.
>
> > 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.
>
>
>
>>>>       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.
>
>
> >      It is true, this is effectively reiterating
> > the guidance of stir-passport. I don't however think this introduces
> > any practical problem.
>
>sigh.
>
>
>>>>       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.
>
>
> > 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.)
>
>
>
>>>
>>>>    For example:
>>>>
>>>>    { "typ":"passport",
>>>>      "alg":"ES256",
>>>>      "x5u":"https://www.example.com/cert.pkx" }
>>>
>>> What is this example demonstrating?  How is the reader to know?
>
> >      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?
>
>
>>>
>>>>
>>>>
>>>>
>>>> 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.
>
> >      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.
>
>
>>>
>>>>
>>>>       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?
>
> >      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.
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    PASSporT object could introduce new claims, and that further SIP
>>>
>>> Future reference to hypotheticals.
>
> >      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.
>
>
>>>
>>>>    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 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.
>
>
>>>
>>>>    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.
>
> >      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...
>
>
>>>
>>>>    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.
>
> >      We plan to have a separate spec to
> > do that, actually.
>
>
>>>
>>>>    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.
>
> > 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.
>
>
>>>
>>>>    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"?
>
>{{ No response from Jon. }}
>
>
>>> And what is the benefit of having this directive?
>
> >      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?
>
>
>>>>
>>>>    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?
>
>{{ No response from Jon. }}
>
>
>>>
>>>>    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?
>
> >      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.
>
>
>
>>>> 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.
>
> >      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 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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>>
>>>> 10.  Backwards Compatibililty with RFC4474
>>>
>>> Delete this section.
>
> >      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.
>
>
>>>
>>>>    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.
>
>{{ No response from Jon. }}
>
>
>>>
>>>> 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.
>
> >      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.
>
>
>>>>    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?
>
> >      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.
>
>
>>>
>>>>
>>>>
>>>>
>>>> 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:[e-mail]) 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.
>
> > 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.
>
>
>
>>>>    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?
>
> >      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.
>
>
>>>
>>>>    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.
>
> > 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.
>
>
>>>>    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
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir