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

[Dave Crocker <[e-mail]>]

Review of:  Authenticated Identity Management in the Session Initiation
             Protocol (SIP)
ID:         draft-ietf-stir-rfc4474bis-10.txt
Date:       8 August 2016
Reviewer:   D. Crocker <[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 publication.



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

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

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

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


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


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

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

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

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

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

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

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




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

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

          an end user originating a SIP request

           cryptographically -> adequately

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


>    interdomain context.  This document defines a mechanism for securely

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


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

> 1.  Introduction
>
>    This document provides enhancements to the existing mechanisms for
>    authenticated identity management in the Session Initiation Protocol
>    (SIP, [RFC3261]).  An identity, for the purposes of this document, is
>    defined as either a SIP URI, commonly a canonical address-of-record
>    (AoR) employed to reach a user (such as
>    'sip:[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 
one.  If the claim is actual enhancement, then what mechanism is 
enhanced and how does authenticating origin constitute enhancement of 
it?  My point is that I believe the existing mechanisms will operate the 
same in the future as they have been.  This spec doesn't change them.

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


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

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


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

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



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

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


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

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

So replace it with:

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


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

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


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

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


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

worth breaking this sentence into two, for better clarity.


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

          however...however


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

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

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

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

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


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

"those JSON object" ?

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

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


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

         header /field/?


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

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

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

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


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

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

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


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

           described -> specified (or defined)

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

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


>    Imagine a case where Alice, who has the home proxy of example.com and
>    the address-of-record sip:[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 proxy authenticates Alice (possibly by sending a Digest
>    authentication challenge), and validates that she is authorized to

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


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

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


>    such as a telephone number.  The proxy authentication service then
>    constructs a PASSporT object which contains a JSON representations of
>    headers and claims which mirror certain parts of the SIP request,
>    including the identity in the From header field.  As a part of
>    generating the PASSporT object, the authentication service signs a
>    hash of those headers and claims with the appropriate credential for
>    the identity (in this case, the certificate for example.com, which
>    covers the identity sip:[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.


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

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


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

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

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


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

        delete first sentence.  it adds no useful information.


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

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


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

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

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


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


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

         can be used to sign the From identity.


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

forward reference.  better to put that material before this.


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

          one or more SIP users -> users

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

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


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

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


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

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


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

          header -> header /field/ ?

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

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

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

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


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

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

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


>    Step 1:


          Step 1:  Authoritative for Identity


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

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


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

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


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

       Step 2:  Authorization

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

[or not] remove


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

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


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

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

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

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


>
>    Step 3:

         Step 3:  Timestamp


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

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


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

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


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

         a corresponding an ?->? a corresponding


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

         baseline PASSporT objects headers
         ->
         a baseline PASSporT objects header


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

header?  or header field?


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

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


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


       Step 5: Canonicalization

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

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


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

"When however"?


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

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


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

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


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

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


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

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


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

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


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

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

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


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

it doesn't do forwarding.


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

redundant detail.


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

headers?  header fields?


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

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


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

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

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


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

        Step 1:  PPT parameter


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

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

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

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


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

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


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

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

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


>
>    Step 2:

        Step 2:  Signature Scope


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

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


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

       Step 3:  Obtain Key


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

Only should?  Why???


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

Verifier returns responses?


>    Step 4:

        Step 4:  Date Window Enforcement


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

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


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

        Step 5: Signature Validation


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

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

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

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


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

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


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

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


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

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

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

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


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

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


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

      this -> thus ?

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

but again, stating what it conveys is redundant.


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

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


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

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


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

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


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

[unnecessary] remove.

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


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

[potentially] remove

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


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

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


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

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


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


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

Huh?

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


>    which authentication is performed.  For non-telephone number user
>    parts, one policy might be as follows: the username given in the
>    'username' parameter of the Proxy-Authorization header MUST
>    correspond exactly to the username in the From header field of the
>    SIP message.  However, there are many cases in which this is too
>    limiting or inappropriate; a realm might use 'username' parameters in
>    Proxy-Authorization that do not correspond to the user-portion of SIP
>    From headers, or a user might manage multiple accounts in the same
>    administrative domain.  In this latter case, a domain might maintain
>    a mapping between the values in the 'username' parameter of Proxy-
>    Authorization and a set of one or more SIP URIs that might
>    legitimately be asserted for that 'username'.  For example, the
>    username can correspond to the 'private identity' as defined in Third
>    Generation Partnership Project (3GPP), in which case the From header
>    field can contain any one of the public identities associated with
>    this private identity.  In this instance, another policy might be as
>    follows: the URI in the From header field MUST correspond exactly to
>
>
>
> Peterson, et al.         Expires January 8, 2017               [Page 13]
>
>
> Internet-Draft                SIP Identity                     July 2016
>
>
>    one of the mapped URIs associated with the 'username' given in the
>    Proxy-Authorization header.  This is a suitable approach for
>    telephone numbers in particular.
>
>    This specification could also be used with credentials that cover a
>    single name or URI, such as [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  ?


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

forward reference


>    verification service implementations to create a baseline means of

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


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

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

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


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

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


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

This is gratuitous implementation advice.  Remove it.

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

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


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


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

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

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

Ditto for "alg".

Ditto for ppt.

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


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

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

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

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


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

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


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

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

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


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

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


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

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

what does scope of the credential'?


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

Looks like this needs to define a STIR Credential Registry.


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

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

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


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

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


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

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


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

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


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

guidance vs. specification?


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

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


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

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

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

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

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


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

remove above paragraph.

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

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

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


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

     [or not] remove


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

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


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

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


>    username portion of a SIP URI (e.g.,
>    'sip:[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.




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

"enroll"???


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

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


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

    Once a telephone number is identified...

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


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

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

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


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

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

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

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

How are they to do this?


>       not, implementations SHOULD convert the number into E.164 format,
>       adding a country code if necessary; this may involve transforming
>       the number from a dial string (see [RFC3966]), removing any

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


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

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


>       that this step may be skipped.  This will be the case, for
>       example, for nationally-specific service numbers (e.g. 911, 112);
>       however, the routing procedures associated with those numbers will
>       likely make sure that the verification service understands the
>       context of their use.
>
>       Other transformations during canonicalization MAY be made in
>       accordance with specific policies used within a local domain.  For
>       example, one domain may only use local number formatting and need
>       to convert all To/From user portions to E.164 by prepending

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

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

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


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

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

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

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


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

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


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

      for the purpose of creating and signing -> for creating

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


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

Why is this significant?  How does it affect processing?


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

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


>
> 7.3.  Authority for Domain Names

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

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


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

must or MUST?


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


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

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

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


>
> 7.4.  URI Normalization

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


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

   transformation  -> transformations


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

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


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

Which ABNF?  Where in the document?  Section 25.1?

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

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


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

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


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

I think the algorithm intended here is:

    1. Parse the SIP/SIPS URI

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

    3. Retain <host>

    done.



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

In other words, just get <host>


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

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


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

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


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

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

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


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

Discussion about future hypotheticals, again.  Remove.


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

Exactly.


>
> 8.  Header Syntax


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


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

header *field*


>    in RFC4474 are deprecated.

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

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


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


Note the use of ABNF here, rather than JSON.

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

<token> isn't defined!!!

<generic-param> isn't defined.

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

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


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

    to -> to the


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

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

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


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

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


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

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

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

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


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

Another algorithm needing to be specified as an algorithm.


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

placed where?

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


>    values corresponding to the designated JSON keys:

Delete the opening clause.


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

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

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

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


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

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


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

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


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

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


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

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


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

Future reference to hypotheticals.


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

What is the import of this observation?

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


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

Except that Passport Section 3.3 says nothing more than:

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

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


>    becomes the signed-identity-string of the Identity header.  The
>    hashing and signing algorithm is specified by the 'alg' parameter of
>    the Identity header and the mirrored "alg" parameter of PASSporT.
>    This specification inherits from the PASSporT specification one value
>    for the 'alg' parameter: 'ES256', as defined in [RFC7519], which
>    connotes an ECDSA P-256 digital signature.  All implementations of
>    this specification MUST support the required signing algorithms of
>    PASSporT.
>
>    The complete form of the Identity header will therefore look like the
>    following example:
>
>   Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
>       eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
>       pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \
>           info=<https://biloxi.example.org/biloxi.cer>;alg=ES256

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


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

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

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


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

"with now claims"?

And what is the benefit of having this directive?

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

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


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

So they will only be able to use one extension?

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


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

This is likely redundant information.


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

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


>
> 10.  Backwards Compatibililty with RFC4474

Delete this section.


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

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



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

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


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

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


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


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

How is that a privacy matter?


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

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


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

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


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

...



-- 

            Dave Crocker
            Brandenburg InternetWorking
            bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net