Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Aug 2016 09:40:59 +0000

Hi,

As Richard said, there is still work to do related to how things look in the wire, especially since we are not going to include the encoded JWT object string in one piece. But, again, I think that is more an 4474bis issue.

I do not, however, think that other "bodies" shall have to clarify the encoding on the wire - that needs to be clear in the core spec (other bodies might profile exactly what information is used to calculate the signature etc).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Richard Shockey<mailto:[email-masked]>
Sent: ‎01/‎08/‎2016 01:04
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

Yep… +1

Dave whats the problem here? What do you want?

We choose JWT for a perfectly rational and technically elegant reasons.  We do know what data we want assert and sign.

On one point we totally agree. I have been less than satisified on how this actually looks on the wire. Examples. Jon has acknoledged this in his presentation in Berlin.

Fine picture from my presentation to the Genband conference BTW.

Where do the claims go in the INVITE.  I’m prepared to accept less than perfect since I know there are other bodies ready to provide guidence in order to accelerate adoption among the vendor community.

We think it will work and we have virturilly the entire US voice communicaitons industry using E164 addressing,  as well at the NRA in the US and elsewhere lined up ready to GO.

I support the last call I have trust the authors can provide revisions that can address some of the issues raised.

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

From: stir <[email-masked]> on behalf of Victor Pascual <[email-masked]>
Date: Sunday, July 31, 2016 at 2:44 PM
To: Christer Holmberg <[email-masked]>
Cc: Chris Wendt <[email-masked]>, "[email-masked]" <[email-masked]>, "Peterson, Jon" <[email-masked]>, IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

Fully agree

On 31 Jul 2016, at 19:54, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I agree with Chris. JWT is NOT a mechanism to sign any arbitrary JSON structure. JWT is a mechanism to sign data, and it uses a specific JSON structure (header, claims etc) for doing so. In addition, it provides a mechanism to signal what data/algorithm is used to calculate the signature.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Chris Wendt<mailto:[email-masked]>
Sent: ‎31/‎07/‎2016 00:08
To: [email-masked]<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; Peterson, Jon<mailto:[email-masked]>; IETF STIR Mail List<mailto:[email-masked]>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05
Hi Dave,

I’m not following your argument that because there isn’t a JSON object to sign, we can’t use JWT?
In general, most/all uses of JWT don’t sign an existing object, a set of claims are constructed into a JSON payload that is signed.
There are JWT defined claims precisely defined to create a secure token intentionally meant to be only signed in a JWT.

So to me, we are more than appropriately using JSON and JWT.

It is in 4474bis, we define the exact information to construct the JSON payload object to be signed, so please refer to that.

There are many advantages to using the JWT construct both for STIR charter specifically and elsewhere.

Is that a bad thing?

-Chris

> On Jul 30, 2016, at 9:03 AM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:
>
> Christer,
>
> Thanks for the background...
>
> On 7/30/2016 4:30 AM, Christer Holmberg wrote:
>> I am the one who originally suggested the usage of JWT. I don't
>> understand the claim that JWT is "outside the context of SIP". JWT is a
>> generic/standardized mechanism how to calculate and encode a signature,
>
> Actually, it isn't.
>
> It's own opening text [RFC 7519] says it is "a compact, URL-safe means of representing claims to be transferred between two parties" but more importantly for this issue, it goes on to say:
>
>   "encoded as a JSON object that is used as the payload of a JSON
>   Web Signature (JWS) structure or as the plaintext of a JSON Web
>   Encryption (JWE) structure"
>
> That is, it provides value-added functions... to a JSON object (structure).  However SIP doesn't have a JSON object to sign.  So the working group has had to invent a JSON-based abstraction of SIP header information and then sign it.
>
> Now it has to invent an encoding for the resulting signature.  It would have to do that for a SIP call, no matter the signature's computational abstraction, but because that abstraction is actually an independent format, it wound up distracting the wg from doing a complete job -- so far, after 3 years -- of defining all the details for a complete authentication mechanism.
>
> From what I can tell of the email record for the wg, the unfortunate part of the discussion about choices here was to count JSON/JWT as something other than an abstraction.
>
> Signing an object requires defining the data over which the signature will be made, and how that data will be fed into the signing algorithm. Necessarily, that defines an abstraction of the data.  (Canonicalization seems to be a common component of that abstraction, for example.)
>
> There might be nothing different or better (or, probably, worse) about JWT in those terms; I haven't tried to evaluate it in those terms.  The problem is that its existence as a distinct format has caused the working group to worry about that new and independent object as distinct from the SIP data being signed, rather than as a computational result that then needs to be stored into the SIP header.  So all of the discussion about what to do with the JWT object is additional wg overhead and, IMO, a complete distraction for the primary task of the working group.  (My guess is that there is also added overall system complexity, but I won't press that concern, at this point.)
>
> Arguments that it's a general mechanism for use in other aspects of this space are always appealing. However they are, so far, without merit in the working group context: There are no specifications for any of those other uses.
>
> And the wg still hasn't resolved the very basic and very essential step of putting the signature into the SIP header.
>
>
>
>>     If we would NOT use JWT we would
>> probably have to define more STIR-specific procedures regarding the
>> calculating/encoding of the signature ourselves. It's better to use a
>> standardized mechanism in my opinion.
>
> Well, yeah, I thought/think that too, which was why I originally suggested adapting DKIM. (DANE might be another relevant choice.)  DKIM offers an extremely high point of departure for SIP header signing.  The continued lack of complete specification details about use with SIP demonstrates that JWT doesn't.
>
>
>> I am also the one who raised the encoding issue in Berlin. But that was
>> not related to the usage of JWT as such, but to the fact that we don't
>> carry the encoded JWT object in one piece in the SIP message. We "split"
>> the object into two pieces, and carry one piece as the Identity header
>> field value, and the other piece as the canon header field parameter
>> value.
>
> Right.  And the point I'm raising is not about the details of that choice but the fact that it still hasn't been made at this very late stage.
>
> Besides merely being a missing, essential bit of system specification, it suggests that the wg is still not completely clear about the concrete use of this capability.
>
>
> d/
> --
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net<http://bbiw.net>
>
> _______________________________________________
> stir mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir
_______________________________________________ stir mailing list [email-masked] https://www.ietf.org/mailman/listinfo/stir

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Aug 2016 13:25:46 -0700

On 7/29/2016 2:11 PM, Dave Crocker wrote:
> On 7/29/2016 10:46 AM, Peterson, Jon wrote:
>> I wouldn't say it's a correction to the STIR charter - the charter was
>> always clear that it was not limited to SIP (see the bits about "one or
>> more non-SIP hops" and "out-of-band mechanism" in the charter). But given
>> that our original signing mechanism was, as I said, a concatenation of
>> SIP
>> header field values, the intervention was that other protocols would need
>> something less bound to SIP. JWT turned out to be the solution that the
>> group had consensus to adopt.
>
> JWT has nothing to do with SIP.  So when applied to a SIP context, it's
> entirely artificial.  And yes, I noted the views that thought it simpler
> or equivalent to the computed string, but could not see the explicit
> logic that made JWT a better choice, no does it seem obvious to me.
> Quite the contrary.
>
> Note that during the wg session in Berlin there was /still/ question
> about where to put the JWT information.

Folks,

I'm citing the above text, for discussing the concern I rasied about 
JWT/JSON use in Passport, because that was the first time I criticized 
it, which was several rounds of postings after I sent my review.  That 
is, it was /not/ part of my review.  I made a conscious choice to leave 
that concern out, although I already saw it as likely problematic.

On its face, yes it looks like a reasonable choice.  It's pre-existing 
technology and it looks clean.  The concerns develop in its application, 
not its concept.

Look for JSON and JWT in SIP.  You won't find it.  That means that it is 
an added layer of specification.  Or, in this case, specifications.  And 
since JSON and JWT are their own environments, that means there is a 
learning curve and other baggage to carry, before it is useful to SIP 
and STIR.

Even better is that even the STIR specification for SIP does not require 
using JWT or JSON.  Note that ppt is optional.  This adds to the view 
that, at best, JWT/JSON is really just an abstraction for STIR.

But in fact the fact that ppt is optional really means that the SIP STIR 
specification has added complexity, with very unclear benefit.

As for the underlying justification for the Passport model, references 
to broader applicability are always appealing, but lacking concrete 
specifications and clear, documented intentions of use -- including a 
clear explanation of the benefit to be gained by the abstraction -- they 
turn out mostly to be a distraction from the immediate concern, namely 
added complexity to the mainstream use.

Again: JSON/JWT adds a layer (or two) of mechanism that almost certainly 
is not needed and almost certainly adds problematic complexity to the 
specification, probably to the point of impeding reader comprehension.

As I've noted, the underlying task here is pretty straightforward:

    *  Define a mechanism for finding and validating a public key.

    *  Decide on scope and canonicalization of data to be signed. Define
       a signing mechanism.

    *  Define a validation mechanism.

    *  Decide how to deal with partial adoption

    *  Decide how to deal with broken signatures.

Maybe a little more than this, but not much.

d/

-- 

   Dave Crocker
   bbiw.net

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Aug 2016 16:45:52 +0000

Hi Dave,

Since this discussion seems to be about JSON and SIP in general, perhaps it should be moved to SIPCORE?

Note that I am authoring another draft (not related to STIR), which also defines a signature calculated based on SIP header field information. It has been suggested - by one of the SIPCORE chairs - to calculate and carry the signature as a JWT :)

Regards,

Christer

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Aug 2016 09:59:22 -0700

Christer,

Gosh, I hope not.

My focus is currently only on the STIR effort. The use of json/jwt has 
been raised, discussed, and justified solely within the STIR wg, from 
what I've read of the archive.  So it can and should be considered 
within STIR.

If the comments have applicability beyond STIR, that's fine but that's 
not my immediate concern.  Feel free to copy them over if you wish, of 
course.

d/
-- 

   Dave Crocker

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 4 Aug 2016 13:03:04 -0400

> Note that I am authoring another draft (not related to STIR), which also defines a signature calculated based on SIP header field information. It has been suggested - by one of the SIPCORE chairs -…

I have been loosely following this discussion. IIUC, one of Dave's 
arguments is that SIP implementations don't currently involve JSON, so 
introducing it with STIR will further complicate those implementations.

But, again IIUC, the use of JSON with passport doesn't require anyone to 
*parse* JSON. It is only necessary to *generate* a very special purpose 
JSON and then generate a signature over it.

If I'm right about that, the use of JSON will be no particular burden. 
It doesn't require a JSON "stack". Generating it is hardly more 
complicated than what it replaced: generating a string that is a 
concatenation of a number of bits of data separated by colons.

I don't see what the problem is.

	Thanks,
	Paul

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Aug 2016 11:41:21 -0700

> JSON and then generate a signature over it.

Clever point.  I think you are correct, except for the contents of the 
so-called "ppt" parameter, which does require parsing.

Now about JWT...?  From my reading, so far, I suspect the answer for JWT 
is the same as for JSON?

d/
-- 

   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 06:45:29 +0000

Hi,

The receiver needs to be able to parse JSON if the sender includes the claims, in order to verify the signature.

Also, whatever headers we include, I assume the receiver should be able to parse them.

But, parsing JSON is not a difficult thing to do, and there are available libraries for those who don't want to implement the parser themselves.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Dave Crocker<mailto:[email-masked]>
Sent: ‎04/‎08/‎2016 21:41
To: Paul Kyzivat<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

d/
--

   Dave Crocker

[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Aug 2016 07:20:12 -0700

Christer,

On 8/4/2016 11:45 PM, Christer Holmberg wrote:
>
> The receiver needs to be able to parse JSON if the sender includes the
> claims, in order to verify the signature.

Alternatives and options make specifications more complex and often 
introduce potential non-determinacies.  So the 'if' that you cite is not 
a small matter.

In practical terms, the 'if' means that verifiers must be able to parse 
json as well as encode it.

> But, parsing JSON is not a difficult thing to do, and there are
> available libraries for those who don't want to implement the parser
> themselves.

Just to make sure this sub-thread retains its context:  I did not 
comment on the choice of JSON/JWT in the actual review.  It's not an 
irrational or horrible choice.

But it does add overhead.  It adds it to the effort needed to understand 
the specifications.  And it adds it to the software.  (It might also add 
it to the execution of the software, but I suspect that is, at worst, a 
negligible difference here.)

One of the more deceptive parts of writing standards is the seduction of 
"is not a difficult thing to do".  In most cases where that sort of 
comment is offered, it is quite true.  The problem is with incremental 
complexities.  A not-difficult here; a not-difficult there... They 
really do mount up.

By way of example, having to send the reader off to become proficient in 
two additional specifications is not a small increment in developmental 
overhead, especially when those specification have no natural -- ie, 
pre-occurring -- relevance to the current work.

d/
-- 

   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 20:03:09 +0000

Hi Dave,

I don't know whether the WG has yet decided whether there will be options and alternatives (i.e. whether sending of claims/headers will be mandatory, optional or forbidden) - so we don't yet know whether there will be an "if" :)

But, if there will be an "if", 4424bis needs to describe how to correctly handle the different options and alternatives.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Dave Crocker<mailto:[email-masked]>
Sent: ‎05/‎08/‎2016 17:20
To: Christer Holmberg<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Christer,

d/
--

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Aug 2016 13:10:57 -0700

On 8/5/2016 1:03 PM, Christer Holmberg wrote:
> I don't know whether the WG has yet decided whether there will be
> options and alternatives (i.e. whether sending of claims/headers will be
> mandatory, optional or forbidden) - so we don't yet know whether there
> will be an "if" :)
>
> But, if there will be an "if", 4424bis needs to describe how to
> correctly handle the different options and alternatives.

Thanks for nicely introducing an underlying question I have about the 
specs:  They were submitted for last call but clearly aren't yet 
finished.  What's up with that?

d/

-- 

   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 22:41:27 +0000

Hi,

draft-4424bis was not submitted for last call, was it?

Regards,

Christer

Sent: ‎05/‎08/‎2016 23:11

d/

--

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Aug 2016 15:52:12 -0700

> Subject: [stir] WG Last Call for RFC4474bis
> Date: Wed, 13 Jul 2016 15:58:10 -0400
> From: Russ Housley <[email-masked]>
> Reply-To: IETF STIR Mail List <[email-masked]>
> To: IETF STIR Mail List <[email-masked]>
>
>
> The authors of the Authenticated Identity Management in SIP document
> (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-10.txt) have
> stated that the document is mature and ready for WG Last Call.

-- 

   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Aug 2016 23:05:10 +0000

If that's the case, I assume the issues I raised will be treated as as WGLC comments.

Regards,

Christer

Sent: ‎06/‎08/‎2016 01:52

--

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 6 Aug 2016 17:50:29 +0000

Briefly, there is and always has been a "bare minimum" set of headers and claims that are mandatory for PASSporT. Ultimately, the question of what headers and claims are mandatory in PASSporT is a stir-passport question. SIP as a using protocol of PASSporT defines only which fields in a SIP request will populate those mandatory components of a PASSporT object, and that information is given in considerable detail in RFC 4474bis today.

Extensions may propose additional claims that will appear in PASSporT objects. The extensibility model of PASSporT is similarly a matter for the PASSporT spec rather than RFC 4474bis, though we anticipate that extensions may want to specify some initial using protocol behavior as well. We should have a few examples of that soon.

Jon Peterson
Neustar, Inc.

Sent from my iPad

On Aug 5, 2016, at 4:03 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dave,

Regards,

Christer

Christer,

d/
--

   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 7 Aug 2016 11:10:00 +0000

Hi Jon,

My point is that (as you also wrote) how PASSporT is used with SIP is covered in 4424bis. Whether the current text is sufficient enough or not is a separate discussion, not related to draft-passport.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Peterson, Jon<mailto:[email-masked]>
Sent: ‎06/‎08/‎2016 20:50
To: Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Jon Peterson
Neustar, Inc.

Sent from my iPad

Hi Dave,

Regards,

Christer

Christer,

d/
--

   Dave Crocker

---

From: Richard Shockey <[email-masked]>
Date: Sun, 07 Aug 2016 12:45:58 -0400

Did someone mention examples? 

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Sunday, August 7, 2016 at 7:10 AM
To: "Peterson, Jon" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Paul Kyzivat <[email-masked]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Hi Jon,

Regards,

Christer

From: Peterson, Jon
Sent: ‎06/‎08/‎2016 20:50
To: Christer Holmberg
Cc: [email-masked]; Paul Kyzivat; [email-masked]
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Jon Peterson

Neustar, Inc.

Sent from my iPad

On Aug 5, 2016, at 4:03 PM, Christer Holmberg <[email-masked]> wrote:

Hi Dave,

Regards,

Christer

From: Dave Crocker
Sent: ‎05/‎08/‎2016 17:20
To: Christer Holmberg; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Christer,

d/
-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 7 Aug 2016 17:12:48 +0000

:)

Jon Peterson
Neustar, Inc.

Sent from my iPad

On Aug 7, 2016, at 11:51 AM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

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

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Sunday, August 7, 2016 at 7:10 AM
To: "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Hi Jon,

Regards,

Christer

Jon Peterson
Neustar, Inc.
Sent from my iPad

Regards,

Christer

d/
--

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Aug 2016 14:21:41 -0700

On 8/6/2016 10:50 AM, Peterson, Jon wrote:
> Briefly, there is and always has been a "bare minimum" set of headers
> and claims that are mandatory for PASSporT. Ultimately, the question of
> what headers and claims are mandatory in PASSporT is a stir-passport
> question. SIP as a using protocol of PASSporT defines only which fields
> in a SIP request will populate those mandatory components of a PASSporT
> object, and that information is given in considerable detail in RFC
> 4474bis today.
>
> Extensions may propose additional claims that will appear in PASSporT
> objects. The extensibility model of PASSporT is similarly a matter for
> the PASSporT spec rather than RFC 4474bis, though we anticipate that
> extensions may want to specify some initial using protocol behavior as
> well. We should have a few examples of that soon.

I've read through the above a few times, to make sure I understood it. 
(Really, it did take more than once.)

The role being played by passport is to aid in authentication of the SIP 
caller-id information.  In terms of STIR's charter and the current round 
of specifications, that's is sole role. (I've phrased it with a generic 
term like 'caller-id' in order to encompass the variations that provide 
the value to be validated.)

In spite of having carefully read the passport spec and slogging through 
the rfc4474bis spec, I had not fully appreciated the level of 
indirection and complexity being introduced with the passport construct, 
until your note above.

This isn't just an encoding abstraction.  It's an entirely independent 
layer of complex mechanism, where the actual job that needs to be done 
is just finding a key and then hashing and signing some SIP header 
information.

The aggregate complexity and indirection of the specs developed so far 
seem to make it essentially impossible to determine a specific usage 
scenario that is viable.  And from what I can tell, this includes an 
inability to determine what details are yet to be specified, before 
there is core, usable capability that can operate over the Internet.

d/
-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 8 Aug 2016 21:44:56 +0000

PASSporT is indeed an object format in its own individual specification,
if that's what you mean by the "level of indirection". I consider it a
point of architectural modularity. The working group agreed to organize
the work this way because we did not want to tie STIR too closely to any
particular using protocol (such as SIP). The actual job that needs to be
done here is mitigating the threats defined in our charter and threat
model, which are not specific to SIP. Even though we've repeatedly
explained to you that this independence from SIP was the motivation for
adopting PASSporT, it still does not seem to be sinking in, as you keep
saying things below about how the role of PASSporT is SIP-specific.

Although you seem to feel that this modularity is for some reason a matter
of impossible complexity, the working group, as far as I can tell, is
comfortable with this architecturally. I'm aware of a couple of early
implementations, of running code that does this today. While the situation
you describe sounds very alarming, it is also as far as I can tell utterly
detached from reality. If there's a practical problem here worthy of a
fundamental reconsideration of our direction, it is not coming through in
your objections.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Aug 2016 15:18:42 -0700

> if that's what you mean by the "level of indirection". I consider it a

It's not.  It's more than that.

The small thread that eventually produced your note was debating support 
for format processing and whether it was a requirement for a verifying 
entity to support the syntax.  The conclusion was that it does.

My point, however, is that you note makes clear there is an entire 
semantic engine embodied in Passport that is independent of SIP and 
independent of 4474bis.  That engine needs care and feeding, just like 
any other networking service.

Think carefully about the language you used:

      "... bare minimum" set of headers
and claims that are mandatory for PASSporT. Ultimately, the question of
what headers and claims are mandatory in PASSporT is a stir-passport
question...will populate those mandatory components of a PASSporT
object...Extensions may propose additional claims..."

That's an entity that is more than just a format.

> point of architectural modularity.

Yes, and it's appealing.  I /like/ modularization too.  That's why it 
has taken be awhile to appreciate how much downside this particular 
modularization is introducing.

If there were a variety of specifications that used and benefited from 
all that generality, it might be defensible.  But the specifications in 
front of us today merely show added complexity, making concrete analysis 
challenging.

At that, it's pretty clear that the specifications in front of us are 
still significantly incomplete.  That is, they are insufficient for 
developing a working caller-id authentication service.

  The working group agreed to organize
> particular using protocol (such as SIP).

I understand the motivation.  Really I do.  But after 3 years, SIP is 
all you've got and even that isn't complete.

  The actual job that needs to be
> model, which are not specific to SIP.

That phrasing is common in the email anti-abuse community too.  Threats 
(attacks) are what motivate the work, and so threats are what everybody 
focuses on.

However the underlying nature of the current solution path in fact is 
not to 'prevent' misbehavior, but rather to have a way of detecting 
valid behavior.  That is, rather than a focus on MIStrust, 
authentication focuses on Trust... of the identifier.  (The actor 
associated with the identifier might not be a good actor, but assessing 
that is a separate matter.)  Again: It seeks to validate something, 
rather than to find things that aren't valid.

Those sound obviously related but in fact they require entirely 
different operational modes.

Consequently, I'll claim that the working group task isn't really to 
mitigate threats but to create a basis for trusting a caller-id, and 
I'll claim that that difference in wording has fundamental import.

That the mechanism for doing this is resistant to those threats is 
merely an enticing distraction, because nothing in this work is going to 
stop that folk from creating false caller-ids.

Really.

Consider that point a bit...  Over 90% of email traffic across the open 
Internet is still spam.  However the mail that comes in with SPF and/or 
DKIM protection constitutes a clean channel of authorized identifiers. 
Mail coming through that channel can be handled differently that mail 
coming through the messy, unauthenticated channel.  (And for folk who 
know something of the way actual filtering engines work, yes, I'm being 
simplistic.)

Even though we've repeatedly
> saying things below about how the role of PASSporT is SIP-specific.

Actually, I've been careful to distinguish theory from fact.  I said 
that the actual /use/ is for SIP.

After 3 years, there are no other specifications than for SIP.  And even 
that is incomplete.

> of impossible complexity, the working group, as far as I can tell, is

Marshall Rose once noted that with enough thrust, even pigs can fly.  So 
I've been careful not to say or imply anything quite as absolute as 
'impossible'.

d/

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 8 Aug 2016 22:36:20 +0000

>front of us today merely show added complexity, making concrete analysis

Actually, as I've also already pointed out, our charter constrains us from
working on the non-SIP parts until the "in-band" SIP using protocol is
complete. Which is why, as you say, some years have gone by and the SIP
use case is the only one we are putting forward for an RFC now. That said,
I could point for example to Cullen's rtcweb STIR draft as an example of
the direction the STIR work is going - the lack of discussion of that is
entirely an artifact of the charter here. This modularity is eminently
defensible.

>developing a working caller-id authentication service.

We still have some clean-up to do as a result of the last call comments, I
won't argue with that. And yes, we are trying not to drag our feet at this
point but to move aggressively to address something that the industry and
regulators are quite urgently demanding. But the strong claim that you
can't develop a solution based on this work has not been established by
your intervention, and would seem to depend much more on the likelihood of
implementation and deployment than your newcomer's impression of the
wisdom of the architecture. I've seen this code run myself. I hear a lot
of implementers and operators participating in this discussion who do not
share your anxiety on this point. Why do you know better than them?

Jon Peterson
Neustar, Inc.

P.S. 

>coming through the messy, unauthenticated channel.

Once again, I see no reason to revisit this working group's consensus and
undo our years of work to start over with a technology that you helped
design for email.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Aug 2016 15:45:08 -0700

On 8/8/2016 3:36 PM, Peterson, Jon wrote:
> won't argue with that.

Good to hear.

A small point of process...

My review of Passport includes items for discussion, not only specific 
and easy suggestions for documentation changes.

In order to avoid having authors do a guessing game about what will 
resolve questions and concerns, they normally pursue those items on the 
working group's mailing list.

I hope that will be happening here, rather than, for example, having the 
authors go off and draft what they think will resolve non-trivial 
issues, without seeking working group review and agreement first...

d/

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 8 Aug 2016 23:03:05 +0000

While I will leave it to the chairs to decide how the consensus of the
group on such points should be measured, I might suggest an alternative
approach. 

As your review of PASSporT is quite exhaustive, and is a mix of stylistic
concerns, philosophical concerns, and technical concerns, perhaps you
could narrow those down for the group into a list of explicitly
non-trivial blocking issues. Where you can forge a consensus on the list
for those changes to be made, we editors will happily implement them in
the specs. To date, I have not heard a lot of support for the general
direction you seem to be going, and I'm not sure our consensus process
requires us to satisfy all parties to a discussion.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Aug 2016 16:06:27 -0700

> non-trivial blocking issues.

Jon,

I produced a careful review.

It's not that difficult to distinguish questions from non-questions or 
even to distinguish substantive from editorial comments.

d/

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 8 Aug 2016 23:14:05 +0000

In that case, if the list has heard your issues, I'd be interested in
knowing how much support there is for implementing the changes you
proposed.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Aug 2016 16:24:06 -0700

Jon,

It appears you misread my note.  What I asked for was that the feedback 
I provided be processed in the usual way it is done in the IETF.

That is:

On 8/8/2016 3:45 PM, Dave Crocker wrote:
> resolve questions and concerns, they normally pursue those items on
> the working group's mailing list.

Unless things are done differently in this part of the IETF, it is not 
considered normal IETF process to request working group consensus about 
whether to respond to the details of a review...

But perhaps the word 'respond' is unclear?  In the IETF it means to give 
meaningful responses.  That's quite different from, say, automatically 
expecting suggestions to be agreed to.

d/
-- 

   Dave Crocker

---

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

I responded to your PASSporT review here:

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

That was the response that I anyway believed the points in your review
warranted: I addressed what I took to be your main concerns, while
promising to incorporate some of your minor points in the next revision.
Since then, we've been talking about what major changes should or
shouldn't be made to the architecture as a result of your review. If you
think there's something else that the process guarantees you from a
response, or if my response doesn't address your major points, tell us
what you want to talk about.

Jon Peterson
Neustar, Inc.

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Aug 2016 16:52:56 -0400

It is not fun for a WG Chair to take a vacation and then return to find that WG Last Call discussion has escalated from a straight forward document review to accusations of bad acts on the list.  Well, that is where I find myself, so I’d like to take a step back and try to focus this energy in a productive direction.  First, I think that recounting a bit of history may be helpful.

Well before the STIR BOF, there was consensus that the solution needed two parts.  First, there needed to be a digital signature that covered the claimed source telephone number and some other things to prevent replay.  Second, there needed to be credentials to provide the public key to validate that signature.

During the STIR WG chartering discussion we talked about where that signature might be carried.  We got direction from the Area Director that we should focus on in-band mechanisms before looking at out-of-band mechanisms.  The STIR WG charter gives direction:

   As its priority mechanism work item, the working group will specify a 
   SIP header-based mechanism for verification that the originator of a SIP 
   session is authorized to use the claimed source telephone number, where 
   the session is established with SIP end to end.

The WG decided that a replacement to RFC 4474 was the best way to accomplish this, and the first WG draft on that topic was adopted in June 2014.

Before the STIR BOF, there was discussion about the type of credential that would best scale to represent the telephone number space.  The WG recognized that using certificates for the credential meant that some aspects of the public key infrastructure associated would need to be left to the regulators in each country.  This is a political reality associated with telephone numbers.  This was discussed and understood.  See the hum results regarding credential format at IETF 90 in July 2014:

   https://www.ietf.org/proceedings/90/minutes/minutes-90-stir

The WG decided on certificates for the credential format, and the first WG draft on that topic was adopted in October 2014.

In most of 2015, the WG was making slow progress.  Frankly, I was a bit frustrated; with these fundamental decisions behind us, we could have made faster progress.  But then, we saw renewed energy starting in the Summer of 2015.  One recent example of this can been seen in the blog post from last month by FCC Chairman Wheeler:

   https://www.fcc.gov/news-events/blog/2016/07/22/cutting-robocalls

As part of the renewed energy, there was a suggestion to use the signature format specified by the JOSE WG instead of a bespoke design.  The result was PASSporT, and the first WG draft on that topic was adopted in February 2016.

Now, all three of these documents are in WG Last Call.  It seems that some of the fundamental decisions that were made almost two years ago are being called into question.  If there is a technical problem, let’s identify it and fix it.  If there is a lack of clarity, let’s fix that too.  However, WG Last Call is not the time to revisit each decision that brought the WG to this point.

If you are the author of a review that raises a large technical problem, I ask you to provide a concise description of the problem in a message of its own.  I am trying to separate the discussion of any such problems from the resolution of other document comments.

I ask the authors of each document to review the comments that have been posted and offer a way forward.

Thanks,
Russ

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 17:00:24 -0400

Thanks for this.

May I offer a suggestion?  Let’s ask the authors to submit updates to their drafts that resolve as many of the comments they see as worthy to fix that can be done quickly.  Then let’s ask commenters to look at the diff, identify changes that were NOT made, and use the issue tracker to document them.

That way we can avoid a lot of simple issues in the tracker, and have separate threads for each issue remaining open.

Brian

> On Aug 17, 2016, at 4:52 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Aug 2016 16:58:25 -0700

> May I offer a suggestion?  Let’s ask the authors to submit updates to their drafts that resolve as many of the comments they see as worthy to fix that can be done quickly.  Then let’s ask commenter…

That's often a good suggestion, but I will suggest not in this case.

For each of the documents -- but especially the cert and 4474bis ones -- 
the problems are profound enough to require careful discussion and 
resolution, before changes are safe to make.

d/

-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 20:32:47 -0400

I thought what I suggested would save all of us a lot of time. I guess that
means you should put each of your comments in the tracker then, one issue
per item, small or large and we can discuss each of them one at a time.

Brian

On Wednesday, August 17, 2016, Dave Crocker <[email-masked]> wrote:

>> May I offer a suggestion?  Let’s ask the authors to submit updates to
>> their drafts that resolve as many of the comments they see as worthy to fix
>> that can be done quickly.  Then let’s ask commenters to look at the diff,
>> identify changes that were NOT made, and use the issue tracker to document
>> them.
>>
>
>

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 17 Aug 2016 20:40:29 -0400

+1 (alternatively just do it under FCC auspices
or another venue, e.g., 3GPP SA3, where one
person cannot waste everyone's time.)

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Aug 2016 17:41:36 -0700

On 8/17/2016 5:32 PM, Brian Rosen wrote:
> I thought what I suggested would save all of us a lot of time. I
> guess that means you should put each of your comments in the tracker
> then, one issue per item, small or large and we can discuss each of
> them one at a time.

If a document requires a major rework, then an author's making small
changes without the benefit of knowing what the rework will not be a
good use of their time.  Neither is asking them to guess at the major
changes.

As for your second sentence, it seems a non-sequitur to me.

d/

-- 

   Dave Crocker

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 18 Aug 2016 01:03:56 +0000

Dave

No disrespect sir, but who other than you see that a major rework is required.

Addressing addition of examples plus addressing Christer's comments works for me

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Aug 17, 2016, at 8:41 PM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

d/

--

 Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Aug 2016 18:21:06 -0700

> No disrespect sir, but who other than you see that a major rework is

Martin,

A number of folk who chose to comment privately.  I wonder why they 
don't feel comfortable posting their thoughts publicly?  This is such an 
inviting environment for candid technical exchange.

In fact from what I can tell, these documents have received precious 
little diligent, in-depth review, with a serious concern for their 
intelligibility and comprehensiveness to developers new to these 
documents.

So I'll suggest that some of you take the time to look carefully at my 
comments.  Feel free to filter your reading and only look for whatever 
you consider to be 'major' objections.

And then respond thoughtfully on the list with informed analyses of why 
those objections are not correct or, at least, not worthy of further 
consideration.

d/
-- 

   Dave Crocker

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Aug 2016 09:14:18 -0400

> good use of their time.  Neither is asking them to guess at the major

I disagree.  I just looked again at your comments, and many of them are very easy to handle and they do not have broad impact.  I think the authors can clearly distinguish the two.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Aug 2016 09:11:44 -0400

Tony:

This message is adding a lot of heat, but no light.  Please stop posting personal attacks.

Russ

---

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

I agree with Brian and Russ,

We should not spend a single second discussing whether we e.g. shall use consistent terminology - we shall just do it. GenART, IESG and/or the RFC editor would most likely ask for it anyway, so let's get it done with.

Regards,

Christer

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: 18 August 2016 16:14
To: Dave Crocker <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Setting Direction for the STIR WG Last Call

Russ

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 19 Aug 2016 16:26:16 -0400

Hi Martin,

Congratulations on your getting the Strike
Force meeting and the combined industry
effort underway today.  This engagement
will certainly significantly shape what
ensues in stir as well as the sector.

http://www.attpublicpolicy.com/fcc/fcc-hosts-first-robocall-strike-force-meeting-atts-stephenson-to-chair-industry-led-group/

Could you provide guidance on:
1) repositories of strike force related material?
2) which industry bodies will be engaged in
this effort?
3) how the various industry standard bodies
will be coordinated?

thanks,
tony

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 19 Aug 2016 16:48:02 -0400

Hi Martin et al.,

It is worth noting that for the
upcoming SG17 meeting, China's
MIIT, China Unicom, and China mobile
have proposed a new work item that
is substantially related to stir work.
Indeed, the proposal contains a useful
comprehensive overview of related
SDO activities, including stir, and
a gap analysis.

I expect that the usdel to the meeting
would appreciate any views from the
Task Force and stir participants on
the contribution.  In addition, how does
stir and the IETF anticipate collaborating
with SG17 and the other SDOs going forward?
The NWI seems almost certain to get approved,
and may well be before WTSA 2016.

best,
--tony

---

From: Richard Shockey <[email-masked]>
Date: Fri, 19 Aug 2016 17:01:46 -0400

Details Details ..

J 

From: stir <[email-masked]> on behalf of Tony Rutkowski <[email-masked]>
Organization: Yaana Technologies
Reply-To: <[email-masked]>
Date: Friday, August 19, 2016 at 4:26 PM
To: "DOLLY, MARTIN C" <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: [stir] Robocall Strike Force

Hi Martin,

thanks,
tony

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 19 Aug 2016 17:32:21 -0400

You are not in Kansas (just stir) anymore.
There is a broad international industry,
legal, and institutional constellation in play,
and things are likely to begin moving quickly.
It's challenging, but Martin seems the right
guy to be leading it.
--tony

On 2016-08-19 5:01 PM, Richard Shockey wrote:
>
> Details Details ..
>
> J
>
> *From: *stir <[email-masked]> on behalf of Tony Rutkowski 
> <[email-masked]>
> *Organization: *Yaana Technologies
> *Reply-To: *<[email-masked]>
> *Date: *Friday, August 19, 2016 at 4:26 PM
> *To: *"DOLLY, MARTIN C" <[email-masked]>
> *Cc: *IETF STIR Mail List <[email-masked]>
> *Subject: *[stir] Robocall Strike Force
>
> Hi Martin,
>
> _______________________________________________ stir mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/stir
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Aug 2016 16:25:42 -0700

Russ, et al,

On 8/17/2016 1:52 PM, Russ Housley wrote:
> However, WG Last Call is not the time to revisit each decision that
> brought the WG to this point.

That depends on the nature of the concerns being raised, and it always 
has.  The distinction that has always been made is between engineering 
aesthetics versus basic flaws.

We don't get to reopen an issue if it's really just a matter of 
preference -- I think semicolons are /so/ much better than forward 
slashes, we really do have to change the syntax.  Wrong.

But if someone happens to assess a serious technical flaw -- of the type 
that includes language like "it won't work" -- it doesn't (and 
shouldn't) matter when they notice it.

How the question of the flaw is resolved might matter, but that's a 
separate and later issue.

> If you are the author of a review that raises a large technical
> problem, I ask you to provide a concise description of the problem in
> a message of its own.  I am trying to separate the discussion of any
> such problems from the resolution of other document comments.

Speaking of basic flaws, there's a big one with that request.  I've put 
in an enormous amount of effort formulating comments carefully.

Twice.

You are now requiring me to do even more, for that work to /maybe/ get 
consideration.

That serves as an additional barrier to participation for me.  Even 
without the considerable pattern of abuses, that kind of barrier is 
artificial and exclusionary, in spite of how reasonable it seems.

And there is nothing preventing that extra effort to be done instead by 
the folk tasked with editing the documents. Or anyone else who is 
participating.

I've offered quite a bit of summary text, along with the detailed text. 
So anyone actually wishing to engage in serious discussion can easily 
initiate an email thread for it.

I'm going to post one or two, nonetheless, to test the waters.  But so 
far there appears to be little (no?) significant engagement from the 
general working group to consider the basic issues I've raised.

I'll respond to substantive comments -- and already have been -- but 
absent a change in participant engagement I won't be investing even more 
speculative energy on this.

d/
-- 

   Dave Crocker

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 20 Aug 2016 12:05:06 +0000

Tony,

For deployment in the USA, this ITU work would be totally useless.

The ATIS - SIP Forum is has a profile of the IETF STIR RFC drafts in the SHAKEN Framework document.
Further, SHAKEN telecom industry framework - Signature-based Handling of Asserted Information using Tokens

1.      Defines the architecture and NNI dependencies around the usage of the PASSporT and 4474bis based framework

2.      Defines the security model around management and usage of certificates used to sign and assert caller identity information

In addition, there is a Display Framework document, that defines the requirements for signaling the verification information from the network to the user device and the requirements for what is displayed on the user device independent of technology.

Service Requirements to support the above is being brought into the 3GPP SA1 meeting in San Francisco next week, 8/22-26 (Being led by Greg Schumacher, Sprint).

I will be bring in a discussion paper and CRs into the October CT1 meeting in China with the support of Nokia and Ericsson (and hopefully the other USA companies).

WRT display  on the user device, there will be a combination of vendors getting requirements based on the ATIS-SIP Forum Display Framework given to them as part of ecosystem participation in the FCC Strike Force and/or direct requirements from carriers. In addition, further documentation to in GSMA, Cable Labs, etc... specifications may/will occur.

Up to now, the coordination has been with the ATIS-SIP Forum co-chairs/leaders and moving forward with the FCC Strike Force Authentication Committee (co-chairs Chris Wendt and myself, so there the transition should be seamless)

With the above work plan I do not see a role for the ITU on the Caller ID Spoofing.

Regards,

Martin C. Dolly
Cell: +1.609.903.3360

From: Tony Rutkowski [mailto:[email-masked]]
Sent: Friday, August 19, 2016 4:48 PM
To: DOLLY, MARTIN C <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>; Paul Najarian <[email-masked]>
Subject: Re: [stir] Robocall Strike Force

Hi Martin et al.,

best,
--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 20 Aug 2016 10:27:03 -0400

Hi Martin,

Congratulations again.

This is a very useful overview.  Your providing
ample information at this point is especially
useful for building a common direction.

The "no role" seems like a non-starter.    A better
approach would seem to engage them and any
other fora that emerge as part of the global
constellation you paint.  NFV is an example
where everyone seems to have bought into
that model.  If nothing else, they can produce
TRs that conveys a common model.

It's particularly good to see Greg's SA1
engagement.  Who is working this into GSMA?
ETSI?  3GPP is probably the best global "centroid"
there given its size and stature.

Lastly, given the CA/B Forum's sector
specific expansion of EVcert use, has anyone
engaged them concerning the use of EVcerts?

--tony

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 20 Aug 2016 14:42:02 +0000

Let's take off STIR list for follow on discussions

Reply later today

Martin C. Dolly

On Aug 20, 2016, at 10:27 AM, Tony Rutkowski <[email-masked]<mailto:[email-masked]>> wrote:

Hi Martin,

Congratulations again.

--tony

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Aug 2016 11:17:52 -0400

Martin,

Are these documents (both the SHAKEN stuff and the Display Framework) 
publicly available?

I looked on the sip forum web site but didn't find them.

	Thanks,
	Paul

On 8/20/16 8:05 AM, DOLLY, MARTIN C wrote:
> The ATIS – SIP Forum is has a profile of the IETF STIR RFC drafts in the
> SHAKEN Framework document.
>
> 1.      Defines the architecture and NNI dependencies around the usage
> of the PASSporT and 4474bis based framework
>
> 2.      Defines the security model around management and usage of
> certificates used to sign and assert caller identity information
>
>
>
> In addition, there is a Display Framework document, that defines the
> requirements for signaling the verification information from the network
> to the user device and the requirements for what is displayed on the
> user device independent of technology.
>
>
>
> Service Requirements to support the above is being brought into the 3GPP
> SA1 meeting in San Francisco next week, 8/22-26 (Being led by Greg
> Schumacher, Sprint).
>
>
>
> I will be bring in a discussion paper and CRs into the October CT1
> meeting in China with the support of Nokia and Ericsson (and hopefully
> the other USA companies).
>
>
>
> WRT display  on the user device, there will be a combination of vendors
> getting requirements based on the ATIS-SIP Forum Display Framework given
> to them as part of ecosystem participation in the FCC Strike Force
> and/or direct requirements from carriers. In addition, further
> documentation to in GSMA, Cable Labs, etc… specifications may/will occur.
>
>
>
> Up to now, the coordination has been with the ATIS-SIP Forum
> co-chairs/leaders and moving forward with the FCC Strike Force
> Authentication Committee (co-chairs Chris Wendt and myself, so there the
> transition should be seamless)
>
>
>
> *Martin C. Dolly*
> Email: [email-masked] <mailto:[email-masked]>_
>
>
>
>
>
> *From:*Tony Rutkowski [mailto:[email-masked]]
> *Sent:* Friday, August 19, 2016 4:48 PM
> *To:* DOLLY, MARTIN C <[email-masked]>
> *Cc:* IETF STIR Mail List <[email-masked]>; Paul Najarian
> <[email-masked]>
> *Subject:* Re: [stir] Robocall Strike Force
>
>
>
> Hi Martin et al.,
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 20 Aug 2016 15:41:46 +0000

Being it is joint effort of ATIS and SIP Forum, if you are a member of either, yes. SIP Forum is quite open. But documents are about to be updated.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Saturday, August 20, 2016 11:18 AM
To: [email-masked]
Subject: Re: [stir] Robocall Strike Force

Martin,

Are these documents (both the SHAKEN stuff and the Display Framework) publicly available?

	Thanks,
	Paul

On 8/20/16 8:05 AM, DOLLY, MARTIN C wrote:
> requirements for signaling the verification information from the 
> network to the user device and the requirements for what is displayed 
> on the user device independent of technology.
>
>
>
> WRT display  on the user device, there will be a combination of 
> vendors getting requirements based on the ATIS-SIP Forum Display 
> Framework given to them as part of ecosystem participation in the FCC 
> Strike Force and/or direct requirements from carriers. In addition, 
> further documentation to in GSMA, Cable Labs, etc... specifications may/will occur.
>
>
>
> Authentication Committee (co-chairs Chris Wendt and myself, so there 
> the transition should be seamless)
>
>
>
> Indeed, the proposal contains a useful comprehensive overview of 
> related SDO activities, including stir, and a gap analysis.
>
> I expect that the usdel to the meeting would appreciate any views from 
> the Task Force and stir participants on the contribution.  In 
> addition, how does stir and the IETF anticipate collaborating with 
> SG17 and the other SDOs going forward?
> The NWI seems almost certain to get approved, and may well be before 
> WTSA 2016.
>
> best,
> --tony
>
>
>
>
>

---

From: Richard Shockey <[email-masked]>
Date: Sat, 20 Aug 2016 12:51:45 -0400

+1 to Martin’s comments. The ATIS/SIP Forum NNI TF is going to meet next week to get a debrief on the Strike Force meeting and review the ongoing work plan and documentation.

There are quite a few moving parts here but if this WG can move forward without any new roadblocks we should make considerable progress.

Remember this is not just protocol.  There will be protocol police here.  Chairman Wheeler made that abundantly clear. This is a highly regulated industry. One of the SF groups is specially chartered to look at the regulatory, legislative and law enforcement constructs surrounding implementation. 

— 
Richard Shockey
Shockey Consulting LLC

On 8/20/16, 11:41 AM, "stir on behalf of DOLLY, MARTIN C" <[email-masked] on behalf of [email-masked]> wrote:

    -----Original Message-----
    From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
    Sent: Saturday, August 20, 2016 11:18 AM
    To: [email-masked]
    Subject: Re: [stir] Robocall Strike Force
    
    Martin,

    
    	Thanks,
    	Paul

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Aug 2016 11:31:16 -0700

Martin,

Unless i'm misunderstanding, that actually means no, they are not 
publicly available?

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Aug 2016 11:31:55 -0700

On 8/20/2016 9:51 AM, Richard Shockey wrote:
> There will be protocol police here.

Any idea who?

d/

-- 

   Dave Crocker

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 20 Aug 2016 18:35:13 +0000

Correct sir

Martin C. Dolly

On Aug 20, 2016, at 2:31 PM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

Martin,

Unless i'm misunderstanding, that actually means no, they are not publicly available?

d/

--

 Dave Crocker

---

From: Richard Shockey <[email-masked]>
Date: Sat, 20 Aug 2016 15:10:40 -0400

I can think of several US 3 letter agencies with statutory authority.  The FCC being the principal one. 

— 
Richard Shockey
Shockey Consulting LLC

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

    Any idea who?
    
    d/
    
    -- 
    
       Dave Crocker

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 20 Aug 2016 15:58:20 -0400

Outside the U.S., equivalent domestic agencies
in every national jurisdiction will do the same.
Treaty provisions and operator agreements
should suffice among jurisdictions for international
communications.

--tony

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 20 Aug 2016 20:21:53 +0000

Eating into moose time

What is important is what is signaled on the wire (to steal a phrase from Mr Shockey)

To that end 3GPP CT1 will do it based on ATIS- SIP Forum Display Framework

WRT, cross country treatment and enforcement, company/country agreements
(Above my pay grade)

Martin C. Dolly

On Aug 20, 2016, at 3:58 PM, Tony Rutkowski <[email-masked]<mailto:[email-masked]>> wrote:

--tony

---

From: Richard Shockey <[email-masked]>
Date: Sat, 20 Aug 2016 18:23:04 -0400

++1   

Shockey’s second law. “There is only one network, wireline. Everything else is access.”  You know what Shockey’s first law is.

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Saturday, August 20, 2016 at 4:21 PM
To: "[email-masked]" <[email-masked]>
Cc: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>, Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [stir] Robocall Strike Force

Eating into moose time

(Above my pay grade)

Martin C. Dolly

AT&T

Cell: +1.609.903.3360

Email: [email-masked]

On Aug 20, 2016, at 3:58 PM, Tony Rutkowski <[email-masked]> wrote:

--tony

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Aug 2016 18:52:32 -0400

> Being it is joint effort of ATIS and SIP Forum, if you are a member of either, yes. SIP Forum is quite open. But documents are about to be updated.

I am. I didn't see these among the NNI documents, and didn't find any 
other likely place. Can you supply a URI to where they are?

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 21 Aug 2016 13:22:17 +0000

Paul,

Documents can be found here https://access.atis.org/apps/org/workgroup/ipnni/documents.php , but please use this list to comment, [email-masked] not the STIR list.

Thank you,

Martin

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Saturday, August 20, 2016 6:53 PM
To: DOLLY, MARTIN C <[email-masked]>; [email-masked]
Subject: Re: [stir] Robocall Strike Force

> Being it is joint effort of ATIS and SIP Forum, if you are a member of either, yes. SIP Forum is quite open. But documents are about to be updated.

I am. I didn't see these among the NNI documents, and didn't find any other likely place. Can you supply a URI to where they are?

	Thanks,
	Paul

>> meeting in China with the support of Nokia and Ericsson (and 
>> hopefully the other USA companies).
>>
>>
>>
>> I expect that the usdel to the meeting would appreciate any views 
>> from the Task Force and stir participants on the contribution.  In

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Aug 2016 08:37:04 -0700

Dave,

Whenever we want to add some cryptographic functionality to a protocol [0]
(especially
when it's messaging/object security functionality) we have to ask whether
it would be
better to define something new, specific to the protocol, and hopefully
simple, or reuse
something pre-existing, generic, and presumably more complicated. In my
experience,
the history of those who take the former approach is that we find ourselves
reinventing
a bunch of stuff and that it's not as simple as we hoped [1][2]

Given the difficulty of correctly specifying and implementing this kind of
functionality,
I'd far prefer to stick with a pre-existing component. It doesn't have to
be JSON of course
(for instance, I have no opinion on if COSE would be better) but I would
not be in favor
of defining something specific here.

-Ekr

[0] Or, I guess, in a bunch of other cases.
[1] Indeed, JOSE is in some respects an attempt to apply this treatment to
CMS.
[2] Another example is the current HTTPBIS encryption spec, which has
rather expanded
from its simple origins.

On Wed, Aug 3, 2016 at 1:25 PM, Dave Crocker <[email-masked]> wrote:

> JWT/JSON use in Passport, because that was the first time I criticized it,
> which was several rounds of postings after I sent my review.  That is, it
> was /not/ part of my review.  I made a conscious choice to leave that
> concern out, although I already saw it as likely problematic.
>
> learning curve and other baggage to carry, before it is useful to SIP and
> STIR.
>
> using JWT or JSON.  Note that ppt is optional.  This adds to the view that,
> at best, JWT/JSON is really just an abstraction for STIR.
>
> As for the underlying justification for the Passport model, references to
> broader applicability are always appealing, but lacking concrete
> specifications and clear, documented intentions of use -- including a clear
> explanation of the benefit to be gained by the abstraction -- they turn out
> mostly to be a distraction from the immediate concern, namely added
> complexity to the mainstream use.
>

---

From: Russ Housley <[email-masked]>
Date: Sun, 21 Aug 2016 11:26:09 -0400

Dave:

> That depends on the nature of the concerns being raised, and it always has.  The distinction that has always been made is between engineering aesthetics versus basic flaws.
> 
> We don't get to reopen an issue if it's really just a matter of preference -- I think semicolons are /so/ much better than forward slashes, we really do have to change the syntax.  Wrong.
> 
> But if someone happens to assess a serious technical flaw -- of the type that includes language like "it won't work" -- it doesn't (and shouldn't) matter when they notice it.
> 
> How the question of the flaw is resolved might matter, but that's a separate and later issue.

Your quote dropped a lot of context.  I said:

If there is a technical problem, let’s identify it and fix it.  If there is a lack of clarity, let’s fix that too.  However, WG Last Call is not the time to revisit each decision that brought the WG to this point.

All:

I have asked the the next version of all three documents to be posted.  I believe that will resolve the vast majority of the little things, and then we can better focus on any unresolved technical problems and the places where clarifications are needed.

Russ

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Aug 2016 16:03:50 +0000

Hi Dave,

I agree with Ekr, and being able to use something pre-existing is the reason I asked the passport authors to consider JWT. If you think there is something better pre-existing, please say so, but if you want to do something from scratch I think we’d need some really good justification for that. I don’t agree with your earlier statements that JWT is complex, and there are tons of tools to test and verify JWTs.

In Berlin I did raise an issue on how STIR uses JWT in SIP (the encoded object is “split up”, and different pieces are placed in different SIP elements), but Jon promised to make sure it’s clarified and well explained in the next version of the bis draft, so I think we should give him a chance to do that.

Regards,

Christer

From: stir [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 21 August 2016 18:37
To: Dave Crocker <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Dave,

Whenever we want to add some cryptographic functionality to a protocol [0] (especially
when it's messaging/object security functionality) we have to ask whether it would be
better to define something new, specific to the protocol, and hopefully simple, or reuse
something pre-existing, generic, and presumably more complicated. In my experience,
the history of those who take the former approach is that we find ourselves reinventing
a bunch of stuff and that it's not as simple as we hoped [1][2]

Given the difficulty of correctly specifying and implementing this kind of functionality,
I'd far prefer to stick with a pre-existing component. It doesn't have to be JSON of course
(for instance, I have no opinion on if COSE would be better) but I would not be in favor
of defining something specific here.

-Ekr

[0] Or, I guess, in a bunch of other cases.
[1] Indeed, JOSE is in some respects an attempt to apply this treatment to CMS.
[2] Another example is the current HTTPBIS encryption spec, which has rather expanded
from its simple origins.

On Wed, Aug 3, 2016 at 1:25 PM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

I'm citing the above text, for discussing the concern I rasied about JWT/JSON use in Passport, because that was the first time I criticized it, which was several rounds of postings after I sent my review.  That is, it was /not/ part of my review.  I made a conscious choice to leave that concern out, although I already saw it as likely problematic.

On its face, yes it looks like a reasonable choice.  It's pre-existing technology and it looks clean.  The concerns develop in its application, not its concept.

Look for JSON and JWT in SIP.  You won't find it.  That means that it is an added layer of specification.  Or, in this case, specifications.  And since JSON and JWT are their own environments, that means there is a learning curve and other baggage to carry, before it is useful to SIP and STIR.

Even better is that even the STIR specification for SIP does not require using JWT or JSON.  Note that ppt is optional.  This adds to the view that, at best, JWT/JSON is really just an abstraction for STIR.

But in fact the fact that ppt is optional really means that the SIP STIR specification has added complexity, with very unclear benefit.

As for the underlying justification for the Passport model, references to broader applicability are always appealing, but lacking concrete specifications and clear, documented intentions of use -- including a clear explanation of the benefit to be gained by the abstraction -- they turn out mostly to be a distraction from the immediate concern, namely added complexity to the mainstream use.

Again: JSON/JWT adds a layer (or two) of mechanism that almost certainly is not needed and almost certainly adds problematic complexity to the specification, probably to the point of impeding reader comprehension.

d/

--

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Aug 2016 09:26:48 -0700

> Your quote dropped a lot of context.  I said:

Yes, quite intentionally, so that the focus would be on what I was 
choosing to respond to.

> If there is a technical problem, let’s identify it and fix it.  If
 > there is a lack of clarity, let’s fix that too.

1. You tasked detailed attention to my reviews as a background (behind 
the scenes) task for the editors.

2. You imposed an additional task on me, as I said.

>          However, WG Last
> Call is not the time to revisit each decision that brought the WG to
> this point.

I responded to exactly this point.  I'm not clear what the point of your 
repeating your original statement is, particularly since you seem not to 
be responding to the specifics of my note.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Aug 2016 09:27:21 -0700

d/
-- 

    Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Aug 2016 09:29:41 -0700

On 8/21/2016 8:37 AM, Eric Rescorla wrote:
> Dave,
>
> Whenever we want to add some cryptographic functionality to a
> protocol [0] (especially when it's messaging/object security
> functionality) we have to ask whether it would be better to define
> something new, specific to the protocol, and hopefully simple, or
> reuse something pre-existing, generic, and presumably more
> complicated. In my experience, the history of those who take the
> former approach is that we find ourselves reinventing a bunch of
> stuff and that it's not as simple as we hoped [1][2]

We agree.

I'm not sure what the point of saying here is, since it is highly 
consonant with points I have posted here more than once.

d/

-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Aug 2016 10:00:22 -0700

> consonant with points I have posted here more than once.

Well, I'm still wading through the traffic on the list, so sorry if I
missed them, but I took the message I was responding to be arguing that we
should not use JOSE here but rather should define something specific. Did I
misread you? If so, then I apologize and I would greatly appreciate it if
you could restate what you are proposing.

Thanks,
-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Aug 2016 09:28:03 -0700

On 8/21/2016 9:03 AM, Christer Holmberg wrote:
> I agree with Ekr, and being able to use something pre-existing is the
> reason I asked the passport authors to consider JWT. If you think there
> is something better pre-existing, please say so, but if you want to do
> something from scratch I think we’d need some really good justification
> for that. I don’t agree with your earlier statements that JWT is
> complex, and there are tons of tools to test and verify JWTs.

Christer,

Just to be thorough, I'll repeat that I agree with the goal of using 
existing solutions, where they represent a high-enough point of 
departure (if they aren't a perfect match), preferably with enough track 
record to establish efficacy.

And I'll repeat that my view of the passport draft did not criticize the 
use of JWT.  (By the way, is it only JWT or is it actually JOSE, and if 
it isn't why not?)

It's not that I didn't question the use, it's that I didn't indulge in 
that questioning at that point.  This came later, as I watched the 
documentation efforts to integrate use of JWT.

 > In Berlin I did raise an issue on how STIR uses JWT in SIP (the encoded
 > object is “split up”, and different pieces are placed in different SIP
 > elements), but Jon promised to make sure it’s clarified and well
 > explained in the next version of the bis draft, so I think we should
 > give him a chance to do that.

There are at least two major problems here.

The technical one is that the current approach requires doing encoding 
and packaging twice, from what I can tell.  Once in a JSON context and 
the second in a SIP header context.  By itself, that should be worrying. 
That the latter hasn't been fully documented and agreed to, yet, raises 
a question about how anyone thought the documents were ready for last call.

The other major problem is that the introduction of JSON/JWT has 
produced levels of indirection in the documentation that made it 
essentially impossible for me to understand and analyze the 
specification details.  And I tried pretty hard.  So this does not bode 
well for other new readers of the specifications.  (More generally, the 
documents make cross-references and indulge in cross-dependencies that 
defeat the benefits of modularity and create really serious reading 
complexity.)

And now, yes, I'll indulge in the dreaded "DKIM" reference...

DKIM is another existing mechanism that provides exactly the needed 
functionality, with more than 10 years of field experience (counting the 
predecessor Yahoo's Domainkeys) and a relatively simple design.

As I've noted before, the list of 'topics' for the STIR work is not 
long.  I'll do an abbreviated listing here:

    1. Calling value acquisition -- getting the string to validate

    2. Key management --getting the key and validating that it is
       authorized for use with the calling value.

    3. A bunch of crypto-related computation -- including
       canonicalization of the data of course

    4. Packaging the result -- for use by the validation mechanism.

Step 1 is not part of the crypto work, but it is of course fundamental, 
as well as being specific to STIR.  The crypto subsystem just uses it as 
input. The choice of JSON/JWT, DKIM, or whatever is irrelevant to this step.

Step 2:

   a)  For non-telephone URIs, DKIM's DNS model can be used directly.

   b)  I'm unclear about the role of the domain name in the URIs that 
have a phone number in the left-hand side.  In any event, as I've noted 
repeatedly, number-based key management is an open issue, with 
demonstrated high risk, given that the previous effort failed.

Step 3 can use DKIM almost directly.

Step 4 can use DKIM almost directly.

So the DKIM approach is dramatically simpler and offers by far the 
highest point of departure for STIR.

In particular, the hard parts of doing STIR aren't solved by this choice 
-- JSON/JWT don't help either.

d/
-- 

   Dave Crocker

---

From: Chris Wendt <[email-masked]>
Date: Mon, 22 Aug 2016 13:58:10 -0400

Hi Dave,

Thanks for the review, and apologize for delay for proper response, i just got back from vacation on Saturday.   i have gone through all of your comments and will be submitting a new 06 version of passport, just to make it easier to diff.

Many of the comments/ambiguities were related to some relics of how passport has changed over various revisions, so appreciate the chance to clean them up.  Of course included many clean up of syntax in general, so good to clean them up as well. 

There are a couple of places where I left the text the same, and look for further comment.  In addition, some of the reference and more proceedural stuff i will plan to update in next version.

Comments and actions i took are given inline below, but refer to 06 document for specific changes in text.

Again, thanks for detailed comments.

-Chris

> On Jul 28, 2016, at 1:37 PM, Dave Crocker <[email-masked]> wrote:
> 
> 
> 
> Review of:  draft-ietf-stir-passport-05
> Date:       27 July 2016
> Revied by:  D. Crocker <[email-masked]>
> 
> 
> Summary:
> 
> The 'Persona Assertion Token' specification defines an object containing
> multiple attributes that are intended to be used for authentication,
> integrity and non-repudiation, such as validating the originator of a
> SIP telephone call. The object is intended to be application- and
> transport-independent. In effect, the object links certification details
> to application details and/or transport details.
> 
> Although the text provides details of 'how' to compose a passport token,
> it never actually says what passport is. There are some later comments
> that imply what it is, or seem to assume a knowledge of what it is, but
> it's never defined as a technical construct. By way of example, how does
> it differ from the function of an X.509 cert?
> 
> The specification has problems with its explanation of purpose and its
> apparent scope, as well as occasional lack of clarity or
> correctness. It even has quite a few typographical errors that would
> have been trivially detected by a spelling corrector.
> 
> The document was only first produced in February, with 4 revisions in
> the last 3 months, including one during Last Call. And the recent
> revisions have included quite substantive changes. Discussion about the
> draft on the wg mailing list has been thin. Also, during the wg session
> in Berlin, discussion seemed to include a fair amount of reference to
> what 'might' be done -- eg, tailoring use through profiles or encoding
> for SIP or... -- rather than clarity about how this specification would
> definitely be used. It suggests the possibility of less stability in
> community understanding of the specification than one would wish for an
> IETF proposed standard.
> 
> The document is /not/ ready for publication.
> 
> 
> 
> This appears to be a specification for something that is for far more
> general use than simply doing caller-id authentication; as such it
> appears to go beyond the scope of the working group's charter. This
> might be acceptable, if the solution provided adequately covered what
> /is/ in scope and were still timely and sufficiently 'efficient'. However the working group has taken 3 years to produce this work and there are no other use-cases presented and no other specifications for use, to justify the purported generality. As such, the generality is purely theoretical. Worse, there is a poor track-record of such efforts proving successful at being more general. Instead, they impose the overhead of generality without the benefit.
> 
> The document is written with the apparent expectation that the reader
> has quite a bit of prior knowledge but it isn't stated explicitly. This
> needs to be written for a wider audience than just those already in the
> wg and more than those already familiar with the work. If there are
> specific details the reader must know ahead of time, state or cite them
> early and explicitly
> 
> As an example, the document is really built on top of JWT but doesn't
> introduce the reference or details about this until section 3. (The
> passing reference in section 2 does not explain that JWT is foundational
> to the current work.)
> 
> As to the choice of JWT, it seems odd, since it isn't natural to the SIP context, which is essential for the chartered work, and therefore requires an additional layer of translation for use with SIP.
> 
> The document title and the content use the term 'persona' but there is
> nothing in this document that pertains to any of the normal, technical
> -- or even informal -- uses of the term. So it might be a clever turn of
> phrase, but it appears to be significantly inappropriate, or at least
> misleading. (Perhaps the goal is to sustain the unusual choices that SIP
> made, such as with the term 'identity', deviating from usages in the
> world of online identity?...)
> 
> The document desperately needs a carefully-written terminology section.
> 
> The specification is dominated by heavy focus on the details and
> mechanisms, without much that covers purposes and functions. The text is
> heavy with redundant acronyms usage, to the point of distraction.
> (Imagine specifying http by having every paragraph say that ASCII (or
> Unicode or whatever) is being used. Assert packaging-related details
> only where needed, rather than feeling that every bit of technical
> information must be seasoned with references to JWT, JWS, or whatever.
> 
> Algorithmic details often are specified in non-linear sequence, eg, if B
> do C after doing A and before doing C. This makes it difficult to
> acquire an simple understanding of the sequence. Algorithms need to be
> presented in as linear a fashion as possible, and preferable include
> pseudo-code, to be that much more concise.
> 
> In terms of pragmatics, here are two operational questions that I can't
> answer, based on this specification, and yet they are fundamental to the
> utility of this work.
> 
>      How is key rollover done?
> 
>      How is delegation done, such as for use by authorized third
>      parties?
> 
> As an example that the document needs much more careful proofreading,
> the terms header and headers appear to be used inconsistently and
> possibly incorrectly.
> 
> Also I note that a revision of the draft was posted during Last Call.
> This can create confusion or extra work, to reconcile things. From a
> quick scan of the revision's diff, it doesn't appear that the changes
> affect this review... maybe.
> 
> Also, having a Last Call that overlaps with an IETF meeting is not a
> good way to encourage adequate attention to the production of reviews,
> although the document really needed them.
> 
> 
> 
> 
> 
> Detailed Comments
> -----------------
> 
> 
>> STIR                                                            C. Wendt
>> Internet-Draft                                                   Comcast
>> Intended status: Standards Track                             J. Peterson
>> Expires: January 23, 2017                                   Neustar Inc.
>>                                                           July 22, 2016
>> 
>> 
>>                        Persona Assertion Token
>>                      draft-ietf-stir-passport-05
>> 
>> Abstract
>> 
>>   This document defines a token format for verifying with non-
> 
>  [format] remove  or remove [token]

replied with token object

> 
> Is the timestamp the basis of claiming non-repudiation?

Partially, depending on your interpretation of how non-repudiation is achieved.  The digital signature based on a certificate is the non-repudiation of the original assertion and signing of the token.  The timestamp and including the destination identity adds the ability to further validate that there wasn’t someone illegitimate that simply replayed the sending of the token.

> 
> 
>>   repudiation the sender of and authorization to send information
>>   related to the originator of personal communications.  A
> 
> 'info related to'... what does this mean?

Yes this was a bit too broad and the abstract text wasn’t updated when the scope was reduced.

replaced with:
'non-repudiation the author of the token, their authority to author the token and, minimally, the asserted originating identity or persona contained within the token corresponding specifically to the originator of personal communications'

> 
> 
>>   cryptographic signature is defined to protect the integrity of the
>>   information used to identify the originator of a personal
>>   communications session (e.g. the telephone number or URI) and verify
>>   the accuracy of this information at the destination.  The
> 
> 'accuracy'?  validates authorship, not validity, I suspect.
> 
> A signature's primary purpose usually is authenticate origination, authorship, or the like, where integrity is a side-effect of the methodology.  Integrity as the primary function would typically occur only when the identity of the signer need be no more than something like 'whomever I interacted with previously'.  I suspect that such a session-limited identity semantic is not, in fact, the intent here.

replaced with ‘assertion of the identity information’

> 
> 
>>   cryptographic signature is defined with the intention that it can
>>   confidently verify the originating persona even when the signature is
>>   sent to the destination party over an unsecure channel.  The Persona
> 
>    unsecure -> insecure  (unless the intend is reference to a loan?)

fixed

> 
> 
>>   Assertion Token (PASSporT) is particularly useful for many personal
>>   communications applications over IP networks and other multi-hop
>>   interconnection scenarios where the originating and destination
>>   parties may not have a direct trusted relationship.
>> 
>> Status of This Memo
>> 
>>   This Internet-Draft is submitted in full conformance with the
>>   provisions of BCP 78 and BCP 79.
>> 
>>   Internet-Drafts are working documents of the Internet Engineering
>>   Task Force (IETF).  Note that other groups may also distribute
>>   working documents as Internet-Drafts.  The list of current Internet-
>>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>> 
>>   Internet-Drafts are draft documents valid for a maximum of six months
>>   and may be updated, replaced, or obsoleted by other documents at any
>>   time.  It is inappropriate to use Internet-Drafts as reference
>>   material or to cite them other than as "work in progress."
>> 
>>   This Internet-Draft will expire on January 23, 2017.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 1]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> Copyright Notice
>> 
>>   Copyright (c) 2016 IETF Trust and the persons identified as the
>>   document authors.  All rights reserved.
>> 
>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>   Provisions Relating to IETF Documents
>>   (http://trustee.ietf.org/license-info) in effect on the date of
>>   publication of this document.  Please review these documents
>>   carefully, as they describe your rights and restrictions with respect
>>   to this document.  Code Components extracted from this document must
>>   include Simplified BSD License text as described in Section 4.e of
>>   the Trust Legal Provisions and are provided without warranty as
>>   described in the Simplified BSD License.
>> 
>> Table of Contents
>> 
>>   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>>   2.  Token Overview  . . . . . . . . . . . . . . . . . . . . . . .   4
>>   3.  PASSporT Definition . . . . . . . . . . . . . . . . . . . . .   4
>>     3.1.  PASSporT Header . . . . . . . . . . . . . . . . . . . . .   4
>>       3.1.1.  "typ" (Type) Header Parameter . . . . . . . . . . . .   4
>>       3.1.2.  "alg" (Algorithm) Header Parameter  . . . . . . . . .   5
>>       3.1.3.  "x5u" (X.509 URL) Header Parameter  . . . . . . . . .   5
>>     3.2.  PASSporT Payload  . . . . . . . . . . . . . . . . . . . .   5
>>       3.2.1.  JWT defined claims  . . . . . . . . . . . . . . . . .   5
>>         3.2.1.1.  "iat" - Issued at claim . . . . . . . . . . . . .   5
>>       3.2.2.  PASSporT specific claims  . . . . . . . . . . . . . .   6
>>         3.2.2.1.  Originating and Destination Identity Claims . . .   6
>>         3.2.2.2.  "mky" - Media Key claim . . . . . . . . . . . . .   7
>>     3.3.  PASSporT Signature  . . . . . . . . . . . . . . . . . . .   8
>>   4.  Extending PASSporT  . . . . . . . . . . . . . . . . . . . . .   8
>>     4.1.  "ppt" (PASSporT) header parameter . . . . . . . . . . . .   8
>>     4.2.  Extended PASSporT Claims  . . . . . . . . . . . . . . . .   9
>>   5.  Deterministic JSON Serialization  . . . . . . . . . . . . . .   9
>>     5.1.  Example PASSport deterministic JSON form  . . . . . . . .  10
>>   6.  Human Readability . . . . . . . . . . . . . . . . . . . . . .  10
>>   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
>>     7.1.  Avoidance of replay and cut and paste attacks . . . . . .  10
>>     7.2.  Solution Considerations . . . . . . . . . . . . . . . . .  11
>>     7.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  11
>>   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
>>     8.1.  Media Type Registration . . . . . . . . . . . . . . . . .  11
>>       8.1.1.  Media Type Registry Contents Additions Requested  . .  11
>>     8.2.  JSON Web Token Claims Registration  . . . . . . . . . . .  13
>>       8.2.1.  Registry Contents Additions Requested . . . . . . . .  13
>>   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
>>   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 2]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
>>     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
>>   Appendix A.  Example PASSporT JWS Serialization and Signature . .  15
>>     A.1.  X.509 Private Key Certificate for Example . . . . . . . .  16
>>     A.2.  X.509 Public Key Certificate for Example  . . . . . . . .  17
>>   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
>> 
>> 1.  Introduction
>> 
>>   In today's IP-enabled telecommunications world, there is a growing
>>   concern about the ability to trust incoming invitations for
>>   communications sessions, including video, voice and messaging.
>>   [RFC7340] As an example, modern telephone networks provide the
>>   ability to spoof the calling party telephone number for many
>>   legitimate purposes including providing network features and services
>>   on the behalf of a legitimate telephone number.  However, as we have
>>   seen, bad actors have taken advantage of this ability for
>>   illegitimate and fraudulent purposes meant to trick telephone users
>>   to believe they are someone they are not.  This problem can be
>>   extended to many emerging forms of personal communications.
>> 
>>   This document defines a common method for creating and validating a
> 
> [common] delete

fixed

> 
> 
>>   token that cryptographically verifies an originating identity, or
>>   more generally a URI or application specific identity string
> 
> 'identity string'?  what does this mean?
> 
> 'app string id'? what does this mean?

Removed and replaced with 'URI or telephone number'

> 
> 
>>   representing the originator of personal communications.  Through
>>   extended profiles other information relevant to the personal
>>   communications can also be attached to the token.  The primary goal
>>   of PASSporT is to provide a common framework for signing persona
> 
> What is a 'persona'?  Where is this construct introduced or cited and explained?

‘persona’ replaced with 'originating identity'

> 
> 'profiles'?  Where is this construct introduced or cited and explained?

replaced with 'Through extensions defined in this document'

> 
> 
>>   related information in an extensible way.  A secondary goal is to
> 
> It seems to also be primary.
> 
> (PPT provides a framework for signing related information) ?
> 
> 
>>   provide this functionality independent of any specific personal
>>   communications signaling call logic, so that creation and
>>   verification of persona information can be implemented in a flexible
>>   way and can be used in many personal communications applications
>>   including end-to-end applications that require different signaling
>>   protocols.  It is anticipated that signaling protocol specific
>>   guidance will be provided in other related documents and
>>   specifications to specify how to use and transport PASSporT tokens,
> 
> specs to spec...  awkward phrasing
> 
> as always, a specification that declares what is 'anticipated' moves into purely hypothetical, which too-often proves to be wishful fantasy. The reference doesn't specify anything and it creates a dependency that well might not be satisfied.
> 
> 'tokens'?  Where is this constructed introduced, cited or explained? Use of a term like this implies that there is some distinctive meaning, but really there isn't.  This is a format specification.  That's all.
> 
> If there is a claim that the term token does have significance here, then please explain it.  For example, how is this token to be used?
> 
> If the term is used merely as an inheritance from JWT, then cite that early, to justify the term.

Cleaned up phrasing and defined tokens.

> 
> 
>>   however this is intentionally out of scope for this document.
>> 
>>   Note: As of the authoring of this document,
>>   [I-D.ietf-stir-rfc4474bis] provides details of how to use PASSporT
>>   within SIP signaling for the signing and verification of telephone
>>   numbers.
> 
> remove Note.  Or make it a note to RFC Editor to remove it, or rephrase so it's useful 10 years from now.

Would probably like a reference here, don’t want to just remove.

> 
> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 3]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> 2.  Token Overview
>> 
>>   Tokens are a convenient way of encapsulating information with
> 
> Why?  What are the alternatives?  Why is this the starting point?
> 
> 
>>   associated digital signatures.  They are used in many applications
> 
> Such as?
> 
> Anyhow, this section seems to take the construct of 'token' as being an established term of art.  It isn't.  Or, at least, I've no idea what is meant here that distinguishes a token from anything else, such as other forms of encapsulation.  Say/cite what a token is, if it is such a distinctive thing.  Say/cite how it differs from alternatives, if its superiority is going to be touted.
> 
> 
>>   that require authentication, authorization, encryption, non-
>>   repudiation and other use cases.  JSON Web Token (JWT) [RFC7519] and
>>   JSON Web Signature (JWS) [RFC7515] are designed to provide a compact
>>   form for many of these purposes and define a specific method and
>>   syntax for signing a specific set of information or "claims" within
>>   the token and therefore providing an extensible set of claims.
>>   Additionally, JWS provides extensible mechanisms for specifying the
>>   method and cryptographic algorithms used for the associated digital
>>   signatures.
> 
> Note that there is nothing in the above text that actually explains what a token is or how it differs from things that aren't tokens.

I would challenge the fact that ‘token’ is a term of art, but i suppose maybe it depends on what crowd you run with.  In either case, I defined it as a canonical string object at the beginning of the document.

> 
> 
>> 3.  PASSporT Definition
> 
> This section is not a definition.  It's more like structure, or format, or foundation or encoding.

‘Passport Components'

> 
> 
>>   The PASSporT is constructed based on JWT [RFC7519] and JWS [RFC7515]
>>   specifications.  JWS defines the use of JSON data structures in a
>>   specified canonical format for signing data corresponding to JOSE
>>   header, JWS Payload, and JWS Signature.  JWT defines specific set of
> 
>       specific set -> a set

fixed

> 
> 
>>   claims that are represented by specified key value pairs which can be
>>   extended with custom keys for specific applications.
>> 
>> 3.1.  PASSporT Header
>> 
>>   The JWS token header is a JOSE header [RFC7515] that defines the type
>>   and encryption algorithm used in the token.
> 
> The section starts with structure detail and ends with purpose. This should be swapped.

swapped example and added some text to preface the header parameters

> 
> 
>>   An example of the header for the case of an ECDSA P-256 digital
>>   signature would be the following,
> 
> How is reader to know what that long string means? Is the doc only for
> the cognoscenti? if so, which cognoscenti?

removed cognoscenti terms

> 
> 
>>       {
>>           "typ":"passport",
>>           "alg":"ES256",
>>           "x5u":"https://cert.example.org/passport.cer"
>>       }
> 
>   *** EXPLAIN EXAMPLES, PLEASE ***
> 
> 
>> 3.1.1.  "typ" (Type) Header Parameter
>> 
>>   JWS defines the "typ" (Type) Header Parameter to declare the media
>>   type of the JWS.
> 
> media type?  IANA citation needed.  (It was in an earlier version of the draft!)

was guided to remove it

> 
> 
>>   For PASSporT Token the "typ" header MUST minimally include and begin
>>   with "passport".  This represents that the encoded token is a JWT of
>>   type passport.
> 
> Is it possible to begin with it and not include it?  That is, 'include' is redundant.  'minimally' is also not information, but it raises the question: The other two attributes aren't required???

Yes, missed this in last edits, fixed it to only be “passport” no other option.

> 
> Also, this subsection is part of an Overview.  Why does it have normative content?  Or is this not really an overview?
> 

not part of overview, overview is section 2

> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 4]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> 3.1.2.  "alg" (Algorithm) Header Parameter
>> 
>>   For PASSporT, the "alg" should be defined as follows, for the
>>   creation and verification of PASSporT tokens and their digital
>>   signatures ES256 MUST be implemented.
>> 
>>   Note that JWA [RFC7518] defines other algorithms that may be utilized
>>   or updated in the future depending on cryptographic strength
>>   requirements guided by current security best practice.
>> 
>> 3.1.3.  "x5u" (X.509 URL) Header Parameter
>> 
>>   As defined in JWS, the "x5u" header parameter is used to provide a
>>   URI [RFC3986] referring to the resource for the X.509 public key
>>   certificate or certificate chain [RFC5280] corresponding to the key
> 
> So this service uses a classic X.509 authentication hierarchy?  That's a key design point, only mentioned in a third-level section.

clarified this in overview

> 
> 
>>   used to digitally sign the JWS.  Note: The definition of what the URI
>>   represents in terms of the actor serving the X.509 public key is out
> 
> 'actor serving the X.509 public key' ? what does that mean?

removed

> 
> 
>>   of scope of this document.  However, generally this would correspond
>>   to an HTTPS or DNSSEC resource with the guidance that it MUST be a
> 
>    [a] remove

fixed

> 
> 
>>   TLS protected, per JWS spec.
> 
> This /object/ specification (that is transport independent) dictates /transport/ security???  This is probably wrong, but at least needs careful explanation.
> 

This is mostly a comment towards security consideration recommendation.  I could remove the comment if it’s bothering folks.

> 
>> 
>> 3.2.  PASSporT Payload
>> 
>>   The token payload claims should consist of the information which
> 
> [payload] remove; at best it's redundant
> 
> 'should'?  not MUST?  why?

fixed

> 
>>   needs to be verified at the destination party.  This claim should
>>   correspond to a JWT claim [RFC7519] and be encoded as defined by the
>>   JWS Payload [RFC7515]
> 
> should? why
> 
> correspond???  what does that mean, in technical terms?

fixed to be follows the definition of a JWT claim

> 
> 
>>   The PASSporT defines the use of a number of standard JWT defined
> 
> "The PASSporT" is an affectation.  Both the 'the' and the use of case.

fixed

> 
> 
>>   headers as well as two new custom headers corresponding to the two
> 
> header/s/?
> 
> corresponding?  referring? describing? identifying?  addressing?

fixed

> 
> 
>>   parties associated with personal communications, the originator and
>>   terminator.  These headers or key value pairs are detailed below.
> 
>    These headers or key value pairs are -> This information is
> 

fixed

> 
>>   Key values outside the US-ASCII range should be encoded using percent
>>   encoding as described in section 2.1 of RFC 3986, case normalized as
>>   described in 6.2.2.1 of [RFC3986].  Matching of these values should
>>   use string exact match.
>> 
>> 3.2.1.  JWT defined claims
> 
> When something like this is imported from another spec, there needs to
> be a precise pointer to the specific part of the spec defining it.

This was the text provided by Ted based on discussion in Berlin, but beyond that i’m not seeing what isn’t specific enough.

> 
> 
>> 3.2.1.1.  "iat" - Issued at claim
>> 
>>   The JSON claim MUST include the "iat" [RFC7519] defined claim issued
>>   at.  As defined this should be set to a date cooresponding to the
> 
>   issued at -> "Issued At".
> 
> It would be better to explicitly cite section 4.1.6 in that RFC. Readers should not have to search an entire document to find the detail being referenced.

fixed

> 
> Also, note the MUST here.  I suspect this conflicts with the normative language above in the 'overview’.

I believe i resolved this.

> 
> 
>>   origination of the personal communications.  The time value should be
>>   of the format defined in [RFC7519] Section 2 NumericDate.  This is
>>   included for securing the token against replay and cut and paste
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 5]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>   attacks, as explained further in the security considerations in
>>   section 7.
>> 
>> 3.2.2.  PASSporT specific claims
>> 
>> 3.2.2.1.  Originating and Destination Identity Claims
>> 
>>   Baseline PASSporT defines claims that convey the identity of the
> 
> "Baseline PASSporT defines claims" ?  First reference in a 4th-level section???

Removed baseline

> 
> 
>>   origination and destination of personal communications.  There are
> 
> 'personal'?  so this can't be used by and between companies?  Really, there is nothing about any of this that pertains to the type of users or even the content of the communication.

defined ‘personal communications'

> 
> What is the exact definition or origination and destination?  For example, there is an important distinction between the person making a call vs. the device they are using, versus the provider they are going through.  Which is meant here and how is the reader to know? (cf, call for a terminology section.)

we don’t want to make the distinction here, it’s only about the identity, URI or TN.  whether device or network.  we don’t want to predetermine what the end to end architecture is, this is protocol only.

> 
> 
>>   two claims that are required for PASSporT, the "orig" and "dest"
>>   claims.  Both "orig" and "dest" should have values that are JSON
>>   objects that include identities represented by key value pairs, where
> 
> 'key value pairs' aren't 'claims'?
> 
> should and not must? why?
> 

changed to MUST and clarified

> 
>>   the key represents an identity type and the value is the identity
>>   string.  Currently, these identities can be represented as either
> 
> So, there is expectation of other types?  There needs to be a pointer to an IANA registry.

we do have IANA request for these types, will add text once i figure out how to point to that

> 
> 
>>   telephone numbers or Uniform Resource Indicators (URIs).  The
>>   definition of how telephone numbers or URIs and examples are provided
>>   below.
>> 
>>   The "orig" JSON object MUST only have one key value pair representing
>>   the asserted identity of any type (currently either "tn" or "uri") of
>>   the originator of the personal communications signaling.
>> 
>>   The "dest" JSON object MUST have at least have one key value pair,
>>   but could have multiple identity types (i.e. "tn" and/or "uri") but
>>   only one of each.  Additionaly, in the case of "dest" only, the
>>   identity type key value MUST be an array signaled by standard JSON
>>   brackets, even when there is a single identity value in the identity
>>   type key value.
>> 
>> 3.2.2.1.1.  "tn" - Telephone Number identity
> 
> A document that uses five-levels of section numbering warrants reconsideration of its structure.

fair point, looking for suggestion

> 
> 
>> 
>>   If the originating or destination identity is a telephone number, the
>>   key representing the identity should be "tn".
> 
> should and not must???  why?

fixed

> 
> 
>>   Telephone Number strings for "tn" MUST be canonicalized according to
>>   the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 7.2.
> 
> Actually, this dependency on 4474bis seems odd.
> 
> Given that the phone number construct is at the core of the work here and this is the essential data object, and this object is presumably intended for use outside of 4474bis, I'd expect that canonicalization algorithm to be here.
> 
> If 4474 needs to cite/use the algorithm, it can cite here, which it already will have to do.  There is no other normative use of 4474 in this document.
> 

needs discussion

> 
> 
>> 3.2.2.1.2.  "uri" - URI identity
>> 
>>   If any of the originating or destination identities is of the form
>>   URI, as defined in [RFC3986], the key representing the identity
>>   should be "uri" URI form of the identity.
> 
> should and not must?  why?

fixed

> 
> 
>> 3.2.2.1.3.  Future identity forms
>> 
>>   We recognize that in the future there may be other standard
>>   mechanisms for representing identities.  The "orig" and "dest" JSON
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 6]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>   objects with "tn" and "uri" allow for other identity types with
>>   unique keys to represent these forms.
> 
> Recognition is dandy, but where is the specification detail to support the extensibility?

clarified text

> 
> 
>> 3.2.2.1.4.  Examples
> 
>  *** Explain these examples, so they aren't merely syntax detail ***
> 
> 
>>   Single Originator to Single Destination example:
>> 
>>       {
>>           "dest":{"uri":["sip:[email-masked]"]},
>>           "iat":"1443208345",
>>           "orig":{"tn":"12155551212"}
>>       }
>> 
>>   Single Originator to Multiple Destination Identities example:
>> 
>>       {
>>           "dest":{
>>                   "tn":["12125551212"],
>>                   "uri":["sip:[email-masked]",
>>                       "sip:[email-masked]"]
>>           },
>>           "iat":"1443208345",
>>           "orig":{"tn":"12155551212"}
>>       }
>> 
>> 3.2.2.2.  "mky" - Media Key claim
>> 
>>   Some protocols that use PASSporT convey hashes for media security
>>   keys within their signaling in order to bind those keys to the
>>   identities established in the signaling layers.  One example would be
>>   the DTLS-SRTP key fingerprints carried in SDP via the "a=fingerprint"
>>   attribute; multiple instances of that fingerprint may appear in a
>>   single SDP body corresponding to difference media streams offered.
> 
>        difference -> different?
> 
> The above text belongs elsewhere, explaining the overall set of capabilities, use cases, and the like  In a definitions section like this, focus on definitions, not discussions about use.
> 
> First use of 'SDP', with no explanation of its meaning.

Added citation

> 
> 'DTLS-SRTP' citation?
> 
> And again, how does this citation slip into a transport-independent object signing spec?

Meant to be a useful/likely used example.

> 
> 
> 
>>   The "mky" value of PASSporT contains a hexadecimal key presentation
>>   of any hash(es) necessary to establish media security via DTLS-SRTP.
>>   This mky value should be formated in a JSON form including the 'alg'
>>   and 'dig' keys with the corresponding algorithm and hexadecimal
>>   values.  Note that per guidance of Section 5 of this document any
>>   whitespace and line feeds must be removed.  If there is multiple
> 
> forward pointer.  Sometimes these are necessary, but in general they impede reading comprehension.
> 
> Redundant specification.  Saying here something that is also specified elsewhere in the document invites divergence in reader understanding. Cite, perhaps, but do /not/ summarize.
> 
> Is all of this summary?  Anything new here?  The reader can't tell.
> 
>   "If there is multiple fingerprint values, more than one,"? huh?
> 
> Where do 'dig' and 'alg' come from?  They are not explicitly introduced, even with a citation.

clarified

> 
> 
>>   fingerprint values, more than one, the fingerprint values should be
> 
> should and not must?  why?

fixed

> 
> 
>>   constructed as a JSON array denoted by bracket characters.  For the
>>   'dig' key value, the hash value should be the hexadecimal value
>>   without any colons, in order to provide a more efficient, compact
>>   form to be encoded in PASSporT token claim.
> 
> "in order to provide a more efficient, compact form" is marketing language.  It invites debate while offering no useful technical substance.

removed

> 
> 
>>   An example claim with "mky" claim is as follows:
>> 
>>   For an SDP offer that includes the following fingerprint values,
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 7]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>       a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:
>>       2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
>>       a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:
>>       5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1
>> 
>>   the PASSporT Payload object would be:
>> 
>>       {
>>           "dest":{"uri":["sip:[email-masked]"]},
>>           "iat":"1443208345",
>>           "mky":[
>>           {
>>              "alg":"sha-256",
>>              "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54
>>               F17A03A27DF9B07F4619B2"
>>           },
>>           {
>>              "alg":"sha-256",
>>              "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C
>>               AB3E4B652E7D463F5442CD54F1"
>>           }
>>           ],
>>           "orig":{"tn":"12155551212"}
>>       }
>> 
>> 3.3.  PASSporT Signature
>> 
>>   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.
> 
> 'corresponding to' vs. 'included in’?

corresponding to, public key vs. private key

> 
> 
>> 4.  Extending PASSporT
>> 
>>   PASSporT represents the bare minimum set of claims needed to assert
> 
> represents vs. is or has?
> 
> (FWIW, this isn't quibbling.  It is an example of the difference between regular prose writing and direct, specification language.)

changed to includes

> 
> 
>>   the originating identity and support the secure propoerties discussed
>>   in various parts of this document, however there will certainly be
>>   both new uses and ways of extending the application and usage of
>>   PASSPorT that requires the ability to extend the defined base set of
>>   claims to represent other information requiring assertion or
>>   validation beyond the identity itself.
> 
> there's that 'certainly' again and this time it's predicting the future.
> tsk. don't do that. also, new and extended tends towards redundancy, as
> does the entire sentence's structure. I think the technical statement is:
> 
>      Passport can be extended to support additional claims.
> 
> If you want to get really flowery, you might 'as needed' at the end…

I re-wrote the last sentence here and included 'as needed’ just for the ability to be “flowery” ;)

> 
> 
>> 4.1.  "ppt" (PASSporT) header parameter
>> 
>>   For the extension of the base set of claims defined in this document,
> 
>    For the -> For

fixed

> 
> 
>>   a new JWS header parameter "ppt" MUST be used with a string that
>>   uniquely identifies and points to a profile specification that
>>   defines any new claims that would extend the base set of claims of
>>   PASSporT.
> 
>   extension == profile ??
> 
> What is a profile of Passport?  Where is this defined?
> 
> ('jws header parameter'.)
> 
> What is the purpose of a profile and a profile label?  How is it used?
> 
> 
>   'identifies and points to'?  what does points to mean?

clarified this text

> 
> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 8]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>   An example header with an extended PASSporT profile of "foo" is as
> 
>     profile of -> profile name

changed to PASSporT extension

> 
> 
>>   follows:
>> 
>>       {
>>           "alg":"ES256",
>>           "ppt":"foo",
>>           "typ":"passport",
>>           "x5u":"https://tel.example.org/passport.cer"
>>       }
>> 
>> 4.2.  Extended PASSporT Claims
>> 
>>   Future specifications that define such extensions to the PASSporT
> 
>   [Future] remove
> 
>  [such] remove.  there's no context for it.

removed 

> 
> 
>>   mechanism MUST explicitly designate what claims they include beyond
> 
> designate -> specify  (it's defining, not appointing)

fixed

> 
> 
>>   the base set of claims from this document, the order in which they
>>   will appear, and any further information necessary to implement the
>>   extension.  All extensions MUST incorporate the baseline JWT elements
>>   specified in Section 3; claims may only be appended to the claims
> 
> If all extensions include the baseline, then 'must incorporate' is an odd way to say that

changed to include

> 
> This seems best and first handled by earlier in the spec, by providing a syntax (and text) that shows the base set and then an optional extended set.  With that setup, it is clear that extensions are always /in addition to/ the base.

JSON sort of provides this capability inherently, so would prefer to keep it simple rather than adding more protocol.

> 
> 
>>   object specified; they can never be subtracted or re-ordered.
> 
> What does it mean to be subtracted?  Perhaps 'removed'? Or are they subject to arithmetic modification?

changed to removed, it’s simply just new key value pairs, no manipulation of values.

> 
> 
>>   Specifying new claims follows the baseline JWT procedures ([RFC7519]
>>   Section 10.1).  Note that understanding an extension as a verifier is
>>   always optional for compliance with this specification (though future
> 
> That's not a 'note'; that's a fundamental construct.  It needs to be stated much earlier and much more distinctly and as an explicitly normative assertion.
> 
> Also, this seems to be the first reference to the verifier!
> 
> Also we need a description of the handling of a passport object in terms of creation and consumption.)

modified and clarified

> 
> 
>>   specifications or profiles for deployment environments may make other
>>   "ppt" values mandatory).  The creator of a PASSporT object 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.
>> 
>> 5.  Deterministic JSON Serialization
>> 
>>   In order to provide a deterministic representation of the PASSporT
>>   Header and Claims, particularly if PASSporT is used across multiple
>>   signaling environments, the JSON header object and JSON Claim object
>>   MUST be computed as follows.
> 
> The implication that there can be non-deterministic representations is
> pretty odd and at least needs explanation, assuming the issue is real.

JSON as a canonical format can include spaces and line breaks, etc and make it, from a string format non-deterministic.

We are simply defining a method of authoring JSON deterministically.

In either case, i clarified the message here.

> 
> 
>>   The JSON object MUST follow the rules for the construction of the
>>   thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3.
>>   Each JSON object MUST contain no whitespace or line breaks before or
>>   after any syntactic elements and with the required members ordered
>>   lexicographically by the Unicode [UNICODE] code points of the member
>>   names.
> 
> mumble.

?

> 
> 
>>   In addition, the JSON header and claim members MUST follow the
>>   lexicographical ordering and character and string rules defined in
>>   [RFC7638] Section 3.3.
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017                [Page 9]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> 5.1.  Example PASSport deterministic JSON form
>> 
>>   For the example PASSporT Payload shown in Section 3.2.2.2, the
>>   following is the deterministic JSON object form.
>> 
>>       {"dest":{"uri":["sip:[email-masked]"],"iat": 1443208345,"mky"
>>       :[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442
>>       CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F8
>>       2183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
>>       "orig":{"tn":"12155551212"}}
> 
> Perhaps explain the steps followed to produce this? Perhaps show the
> intermediate forms?
> 

will discuss the need for more explicit instructions, to me, it’s following the spec, but could improve if folks think it’s necessary.

> 
> 
>> 6.  Human Readability
>> 
>>   JWT [RFC7519] and JWS [RFC7515] are defined to use Base64 and/or UTF8
>>   encoding to the Header, Payload, and Signature sections.  However,
>>   many personal communications protocols, such as SIP and XMPP, use a
>>   "human readable" format to allow for ease of use and ease of
> 
> And email and FTP and HTTP and...
> 
> Actually the use of the form has nothing to do with the purpose of the
> application. As noted, it merely makes debugging and monitoring easier.
> 
> 
>>   operational debugging and monitoring.  As such, specifications using
>>   PASSporT may provide guidance on whether Base64 encoding or plain
>>   text will be used for the construction of the PASSporT Header and
>>   Claim sections.
> 
> The section is mislabeled and probably out of scope. It's trying to say
> there there can be alternative encodings of this json object and that
> this spec won't prohibit that happening by other specs.
> 
> In all likelihood, this section should be removed. It doesn't specify
> anything.

removed

> 
> 
>> 7.  Security Considerations
>> 
>> 7.1.  Avoidance of replay and cut and paste attacks
>> 
>>   There are a number of security considerations for use of the token
> 
> I suspect they are not 'security considerations' as much as 'mechanisms' or 'provisions'
> 
> 
>>   for avoidance of replay and cut and paste attacks.  PASSporT tokens
>>   must be sent along with other application level protocol information
> 
> Huh?  You are trying to dictate application-level transport behavior?
> 
> This smacks of layer/scoping violation.

changed to should and removed along, but don’t want to remove this consideration.

> 
> 
>>   (e.g. for SIP an INVITE as defined in [RFC3261]).  There should be a
>>   link between various information provided in the token and
>>   information provided by the application level protocol information.
> 
> Why?

explained

> 
> 
>>   These would include:
>> 
>>   o  "iat" claim should closely correspond to a date/time the message
> 
> The semantics of iat are defined earlier. Either there is compliance or
> there isn't. The discussion here, therefore, should probably say
> something like "a valid iat claim aids in detecting re-use at a later time.”

i am explaining the ‘why’ here, added a sentence about validation and correlation to network time variances.

> 
> 
>>      was originated.  It should also be within a relative delta time
> 
> What is a delta time?  How is the reader to know?  Where is it defined? I suspect what is meant is that it's deviation from time of origination should be small.  If this has a more precise technical definition, then cite it.

removed delta

> 
> 
>>      that is reasonable for clock drift and transmission time
>>      characteristics associated with the application using the PASSporT
>>      token.
> >
>>   o  "dest" claim is included to prevent the ability to use a
>>      previously originated message to send to another destination party
> 
>     the ability to -> using  (or use of)

fixed with ‘valid re-use'

> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 10]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> 7.2.  Solution Considerations
>> 
>>   It should be recognized that the use of this token should not, in
>>   it's own right, be considered a full solution for absolute non-
>>   repudiation of the persona being asserted.  This only provides non-
>>   repudiation of the signer of PASSporT.  If the signer and the persona
> 
> huh?  So the originator isn't really being validated, as claimed???

This is only a statement to recognize that you are only trusting the signer and certificate owner to tell the truth about the originating identity.  If you are familiar with how certificates work, this is an obvious statement, but just a word of consideration.

> 
> 
>>   are not one in the same, which can and often will be the case in
>>   telecommunications networks today, protecting the destination party
>>   from being spoofed may take some interpretation or additional
>>   verification of the link between the PASSporT signature and the
>>   persona being asserted.
>> 
>>   In addition, the telecommunications systems and specifications that
>>   use PASSporT should in practice provide mechanisms for:
>> 
>>   o  Managing X.509 certificates and X.509 certificate chains to an
>>      authorized trust anchor that can be a trusted entity to all
>>      participants in the telecommunications network
> 
> Touching this sort of topic is, at the very best, redundant with
> specifications devoted to X.509. Just cite them and don't attempt to
> repeat them.

I see this as helpful, we can discuss if it’s not needed, but I recall being asked by working group to include text to inform the reader.

> 
> 
>>   o  Accounting for entities that may route calls from other peer or
>>      interconnected telecommunications networks that are not part of
>>      the "trusted" communications network or may not be following the
>>      usage of PASSporT or the profile of PASSporT appropriate to that
>>      network
> 
> Passport doesn't do calls.  Dictating activity involving calls is out of scope.
> 
> On the other hand, perhaps this qualifies for a discussion about transferring passport objects across administrative (trust) domain boundaries?
> 
> At best, this section seems to be trying to compensate for the lack of a framework discussion about the problem domain and the practical uses of the various specifications being produced.

similar to above comment, this is meant to be a cautionary statement and something to consider if you are an implementer.  If you understand the limits of what X.509 based certificate signing and PKI can represent in terms of trust, these are obvious statements, but I think it’s good to include none-the-less.

> 
> 
>>   o  Following best practices around management and security of X.509
>>      certificates
> 
> cf, above, about redundancies. Perhaps this is the bullet that should
> remain, while deleting the other one?

same comment as above.

> 
> 
>> 7.3.  Privacy Considerations
>> 
>>   Because PASSporT explicity includes claims of identitifiers of
> 
>    explicity -> explicitly
> 
>    identitifiers -> identifiers
> 
> 
>>   parties involved in communications, times, and potentially other call
>>   detail, care should be taken outside of traditional protected or
>>   private telephony communications paths where there may be concerns
>>   about exposing information to either unintended or illegitimately
>>   intented actors.  These identifiers are often exposed through many
>>   communications signaling protocols as of today, but appropriate
>>   precautions should be taken.
> 
>    intented -> intended
> 
> 
> awk.
> 
> Illegitimately intended?  What does that mean?

changed to illegitimate

> 
> More fundamentally it isn't clear to me what this is really saying.

pure cautionary/disclaimer text that potential privacy information could be exposed, user beware.

> 
> 
>> 8.  IANA Considerations
> 
> This section just sits here, uncited anywhere else in the document? Each item specified should be referenced in the body of the main specification, with a pointer into this section.

ok, need to investigate proper way to do that

> 
> 
>> 8.1.  Media Type Registration
>> 
>> 8.1.1.  Media Type Registry Contents Additions Requested
>> 
>>   This section registers the "application/passport" media type
>>   [RFC2046] in the "Media Types" registry in the manner described in
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 11]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>   [RFC6838], which can be used to indicate that the content is a
>>   PASSporT defined JWT and JWS.
>> 
>>   o  Type name: application
>> 
>>   o  Subtype name: passport
>> 
>>   o  Required parameters: n/a
>> 
>>   o  Optional parameters: n/a
>> 
>>   o  Encoding considerations: 8bit; application/passport values outside
>>      the US-ASCII range are encoded using percent encoding as described
>>      in section 2.1 of RFC 3986 (some values may be the empty string),
>>      each separated from the next by a single period ('.') character.
>> 
>>   o  Security considerations: See the Security Considerations section
>>      of RFC 7515.
>> 
>>   o  Interoperability considerations: n/a
>> 
>>   o  Published specification: draft-ietf-stir-passport-05
>> 
>>   o  Applications that use this media type: STIR and other applications
>>      that require identity related assertion
>> 
>>   o  Fragment identifier considerations: n/a
>> 
>>   o  Additional information:
>> 
>>      *  Magic number(s): n/a
>> 
>>      *  File extension(s): n/a
>> 
>>      *  Macintosh file type code(s): n/a
>> 
>>   o  Person and email address to contact for further information: Chris
>>      Wendt, [email-masked]
>> 
>>   o  Intended usage: COMMON
>> 
>>   o  Restrictions on usage: none
>> 
>>   o  Author: Chris Wendt, [email-masked]
>> 
>>   o  Change Controller: IESG
>> 
>>   o  Provisional registration?  No
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 12]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> 8.2.  JSON Web Token Claims Registration
>> 
>> 8.2.1.  Registry Contents Additions Requested
>> 
>>   o  Claim Name: "orig"
>> 
>>   o  Claim Description: Originating Identity String
>> 
>>   o  Change Controller: IESG
>> 
>>   o  Specification Document(s): Section 3.2 of draft-ietf-stir-
>>      passport-05
>> 
>>   o  Claim Name: "dest"
>> 
>>   o  Claim Description: Destination Identity String
>> 
>>   o  Change Controller: IESG
>> 
>>   o  Specification Document(s): Section 3.2 of draft-ietf-stir-
>>      passport-05
>> 
>>   o  Claim Name: "mky"
>> 
>>   o  Claim Description: Media Key Fingerprint String
>> 
>>   o  Change Controller: IESG
>> 
>>   o  Specification Document(s): Section 3.2 of draft-ietf-stir-
>>      passport-05
>> 
>> 9.  Acknowledgements
>> 
>>   Particular thanks to members of the ATIS and SIP Forum NNI Task Group
>>   including Jim McEchern, Martin Dolly, Richard Shockey, John Barnhill,
>>   Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for
>>   their review, ideas, and contributions also thanks to Henning
>>   Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark
>>   Miller, and Ted Hardie for valuable feedback on the technical and
>>   security aspects of the document.  Additional thanks to Harsha Bellur
>>   for assistance in coding the example tokens.
>> 
>> 10.  References
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 13]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> 10.1.  Normative References
>> 
>>   [I-D.ietf-stir-rfc4474bis]
>>              Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
>>              "Authenticated Identity Management in the Session
>>              Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-10
>>              (work in progress), July 2016.
>> 
>>   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
>>              Extensions (MIME) Part Two: Media Types", RFC 2046,
>>              DOI 10.17487/RFC2046, November 1996,
>>              <http://www.rfc-editor.org/info/rfc2046>.
>> 
>>   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>>              Resource Identifier (URI): Generic Syntax", STD 66,
>>              RFC 3986, DOI 10.17487/RFC3986, January 2005,
>>              <http://www.rfc-editor.org/info/rfc3986>.
>> 
>>   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
>>              Specifications and Registration Procedures", BCP 13,
>>              RFC 6838, DOI 10.17487/RFC6838, January 2013,
>>              <http://www.rfc-editor.org/info/rfc6838>.
>> 
>>   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
>>              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
>>              2015, <http://www.rfc-editor.org/info/rfc7515>.
>> 
>>   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
>>              DOI 10.17487/RFC7518, May 2015,
>>              <http://www.rfc-editor.org/info/rfc7518>.
>> 
>>   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
>>              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
>>              <http://www.rfc-editor.org/info/rfc7519>.
>> 
>>   [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
>>              Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
>>              2015, <http://www.rfc-editor.org/info/rfc7638>.
>> 
>>   [UNICODE]  "The Unicode Consortium, "The Unicode Standard"",
>>              <http://www.unicode.org/versions/latest/>.
>> 
>> 10.2.  Informative References
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 14]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>>              A., Peterson, J., Sparks, R., Handley, M., and E.
>>              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>>              DOI 10.17487/RFC3261, June 2002,
>>              <http://www.rfc-editor.org/info/rfc3261>.
>> 
>>   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
>>              Housley, R., and W. Polk, "Internet X.509 Public Key
>>              Infrastructure Certificate and Certificate Revocation List
>>              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
>>              <http://www.rfc-editor.org/info/rfc5280>.
>> 
>>   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
>>              Telephone Identity Problem Statement and Requirements",
>>              RFC 7340, DOI 10.17487/RFC7340, September 2014,
>>              <http://www.rfc-editor.org/info/rfc7340>.
>> 
>> Appendix A.  Example PASSporT JWS Serialization and Signature
>> 
>>   For PASSporT, there will always be a JWS with the following members:
>> 
>>   o  "protected", with the value BASE64URL(UTF8(JWS Protected Header))
>> 
>>   o  "payload", with the value BASE64URL (JWS Payload)
>> 
>>   o  "signature", with the value BASE64URL(JWS Signature)
>> 
>>   Note: there will never be a JWS Unprotected Header for PASSporT.
>> 
>>   First, an example PASSporT Protected Header is as follows:
>> 
>>       {
>>           "typ":"passport",
>>           "alg":"ES256",
>>           "x5u":"https://cert.example.org/passport.cer"
>>       }
>> 
>>   This would be serialized to the form:
>> 
>>       {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/
>>           passport.cer"}
>> 
>>   Encoding this with UTF8 and BASE64 encoding produces this value:
>> 
>>       eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
>>       ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
>> 
>>   Second, an example PASSporT Payload is as follows:
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 15]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>>       {
>>           "dest":{"uri":["sip:[email-masked]"]}
>>           "iat":"1443208345",
>>           "orig":{"tn":"12155551212"}
>>       }
>> 
>>   This would be serialized to the form:
>> 
>>       {"dest":{"uri":["sip:[email-masked]"]},"iat":"1443208345",
>>           "orig":{"tn":"12155551212"}}
>> 
>>   Encoding this with the UTF8 and BASE64 encoding produces this value:
>> 
>>       eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd
>>       CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0
>> 
>>   Computing the digital signature of the PASSporT Signing Input
>>   ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS
>>   Payload))
>> 
>>       rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso
>>       jNCpTzO3QfPOlckGaS6hEck7w
>> 
>>   The final PASSporT token is produced by concatenating the values in
>>   the order Header.Payload.Signature with period (',') characters.  For
>>   the above example values this would produce the following:
>> 
>>       eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly
>>       9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
>>       .
>>       eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd
>>       CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0
>>       .
>>       rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso
>>       jNCpTzO3QfPOlckGaS6hEck7w
>> 
>> A.1.  X.509 Private Key Certificate for Example
>> 
>>       -----BEGIN EC PRIVATE KEY-----
>>       MHcCAQEEIFeZ1R208QCvcu5GuYyMfG4W7sH4m99/7eHSDLpdYllFoAoGCCqGSM49
>>       AwEHoUQDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH78YTU8qLS8I5HLHSSmlATLcs
>>       lQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
>>       -----END EC PRIVATE KEY-----
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 16]
>> 
>> Internet-Draft                  PASSporT                       July 2016
>> 
>> 
>> A.2.  X.509 Public Key Certificate for Example
>> 
>>       -----BEGIN PUBLIC KEY-----
>>       MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
>>       78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
>>       -----END PUBLIC KEY-----
>> 
>> Authors' Addresses
>> 
>>   Chris Wendt
>>   Comcast
>>   One Comcast Center
>>   Philadelphia, PA  19103
>>   USA
>> 
>>   Email: [email-masked]
>> 
>> 
>>   Jon Peterson
>>   Neustar Inc.
>>   1800 Sutter St Suite 570
>>   Concord, CA  94520
>>   US
>> 
>>   Email: [email-masked]
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Wendt & Peterson        Expires January 23, 2017               [Page 17]
> 
> -- 
> 
>   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Aug 2016 11:58:36 +0000

Hi,

>> something from scratch I think we¹d need some really good justification
>> for that. I don¹t agree with your earlier statements that JWT is

It¹s actually JWS (JOSE is the name of the generic framework). It¹s
probably
something we should fix too.

> > object is ³split up², and different pieces are placed in different SIP
> > elements), but Jon promised to make sure it¹s clarified and well

The latter is the exact issue I raised, and it must be well documented
(together with examples) how it¹s done.

However, once you done the JSON encoding, I don¹t think you need to do
further ³encoding² (no need to escape characters etc). The idea (afaik) is
to split the encoded string into different pieces, and place those in
different SIP header field/parameters. But, HOW that split is done, and
how the string is re-generated on the receiving side, must be clarified.

>defeat the benefits of modularity and create really serious reading

Assuming PASSPorT is supposed to be something generic, I think we should
avoid normative references to the draft-bis from PASSPorT.

(draft-bis draft obviously have to normatively reference PASSPorT.)

As I have zero knowledge of DKIM, I¹ll let others discuss its¹
applicability to STIR, and whether it¹s better/worse than what we
currently have. But, in general, I don¹t think WGLC is too late for a
beauty contest. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Aug 2016 12:03:03 +0000

>currently have. But, in general, I don¹t think WGLC is too late for a

Correction: I DO think WGLC is too late for a beauty contest.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 06:50:50 -0700

> Correction: I DO think WGLC is too late for a beauty contest.

It is much too late for a debate about aesthetics.  It is never too late 
to fix significant problems.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 08:08:58 -0700

On 8/23/2016 4:58 AM, Christer Holmberg wrote:
> The idea (afaik) is

The need for this additional packaging is a basic specification 
requirement.  (Again, I don't understanding submitting a document for 
last call that is missing basic specification details.)

I also don't understand the need for breaking the json result into 
multiple SIP header fields.

Why isn't it just stuffed into a single header field, like 
STIR-Signature: or the like?

d/
-- 

   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Aug 2016 15:45:42 +0000

Hi,

>> different SIP header field/parameters. But, HOW that split is done, 
>> and how the string is re-generated on the receiving side, must be clarified.
>
> The need for this additional packaging is a basic specification requirement.  (Again, I don't
> understanding submitting a document for last call that is missing basic specification details.)
>
> I also don't understand the need for breaking the json result into multiple SIP header fields.

It's actually within one single header field, but one piece is sent as a header field value, while another piece is sent as a header field parameter value.

Example (simplified):

	Identity: <one-piece>;param=<another-piece>

>Why isn't it just stuffed into a single header field, like STIR-Signature: or the like?

That was my question too. Something like:

	Identity:<the-whole-piece>

But, at the end of the day, I want something that works, and Jon promised to describe how the "splitting" works in the next revision of the draft.

Regards,

Christer

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 08:48:54 -0700

> But, at the end of the day, I want something that works, and Jon promised to describe how the "splitting" works in the next revision of the draft.

Not just how, but why.

What you and I are describing is simple and direct.  Splitting things 
adds another step.  Extra steps need justification.

d/

-- 

   Dave Crocker

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Aug 2016 19:12:22 +0000

Hi,

>> But, at the end of the day, I want something that works, and Jon promised to 
>> describe how the "splitting" works in the next revision of the draft.
>
> Not just how, but why.
>
> What you and I are describing is simple and direct.  Splitting things adds another step.  Extra steps need justification.

I guess Jon should reply to that question, but one reasons was related to the suggestion (I don't think that WG has made a decision, but please correct me if I'm wrong) that it should be optional to send the headers representation of the JWS, as that information (cipher suite etc) can be found in other SIP elements. However, Appendix F of RFC 7575 is unclear on whether it's allowed remove the headers representation from the JWS - the Appendix seems to only talk about not sending the payload representation (which, in the case of SIP, can also be found in other SIP elements). So, there could be cases were one would only send the signature representation of the JWS. 

Regards,

Christer

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 15:51:41 -0700

On 8/23/2016 12:12 PM, Christer Holmberg wrote:
>> What you and I are describing is simple and direct.  Splitting
>> things adds another step.  Extra steps need justification.
>
> I guess Jon should reply to that question, but one reasons was
> related to the suggestion (I don't think that WG has made a decision,
> but please correct me if I'm wrong) that it should be optional to
> send the headers representation of the JWS, as that information
> (cipher suite etc) can be found in other SIP elements.

That just extends the question:  Why are things such as cipher suite in 
a SIP header field, separate from the JWS header-field?

I believe 4474bis gives no insight about the motivations or efficacy of 
any of this.

d/
-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Aug 2016 07:33:52 +0000

>I guess Jon should reply to that question, but one reasons was related to
>the suggestion (I don't think that WG has made a decision, but please
>correct me if I'm wrong) that it should be optional to send the headers
>representation of the JWS, as that information (cipher suite etc) can be
>found in other SIP elements.

What I see minuted from IETF 96 as a decision for this question was "keep
what we have now," in other words, keep "canon" optional. As long as
"canon" is optional, then we need at least to have the ability to convey
"alg" and "ppt" in the Identity header (field!). Practically speaking
though, "alg" exists only to give us some flexibility in case it turns out
in the future that the one algorithm we've specified won't work for us. I
doubt "alg" will be present over the wire much.

> However, Appendix F of RFC 7575 is unclear on whether it's allowed
>remove the headers representation from the JWS - the Appendix seems to
>only talk about not sending the payload representation (which, in the
>case of SIP, can also be found in other SIP elements). So, there could be
>cases were one would only send the signature representation of the JWS.

RFC7515, you mean. And yes, it basically just says "you can have
detachable content" without detailing what that means. The new text in
rfc4474bis-11 will, as promised, go into more detail about this, and
furnish an example.

Jon Peterson
Neustar, Inc.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Aug 2016 07:49:31 +0000

Yes, I mean RFC 7515. For some strange reason I keep on getting the
numbers of the RFCs associated with the STIR work wrong all the time :)

Regards,

Christer

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Aug 2016 14:40:03 -0700

Chris,

Thanks for the followup.  Pruned responses to responses, below...

\
On 8/22/2016 10:58 AM, Chris Wendt wrote:
>> Detailed Comments -----------------
>>> STIR
>>> C. Wendt Internet-Draft
>>> Comcast Intended status: Standards Track
>>> J. Peterson Expires: January 23, 2017
>>> Neustar Inc. July 22, 2016
>>>
>>>
>>> Persona Assertion Token draft-ietf-stir-passport-05
>>>
>>> Abstract
...
> Partially, depending on your interpretation of how non-repudiation is
> achieved.  The digital signature based on a certificate is the
> non-repudiation of the original assertion and signing of the token.

That seems to equate authentication with non-reputation of originator. 
But they aren't the same.

http://security.stackexchange.com/questions/6730/what-is-the-difference-between-authenticity-and-non-repudiation

Worse, the opening sentence above, means that there is no way to know 
what the term applies to or how to validate its use.

At the least, a technical specification should use terms of art 
precisely and should provide enough detail so there is reliable, 
cross-reader understanding of its meaning and appropriateness in the 
document.

When the term refers to something that is foundational-but-partial, such 
as working 'in support of' something else that is detailed outside of 
the specification or hasn't even been detailed anywhere, then there 
needs to be text that explains the basis of that support.

For example, authentication of an identifier used in an email 'supports' 
the development of accurate and reliable reputation assessment for mail 
associated with the identifier.  A specification for authentication that 
makes this assertion but does not specify the detail for achieving that 
use needs to explain the claim, such as:  It does that by ensuring that 
the identifier's use is only by authorized entities, thereby eliminating 
the reputation analysis 'noise' from unauthorized use of the identifier 
in messages.

The current spec needs to similarly explain/justify a claim of use for 
non-reputation, but with something more substantive and reliable than 
"depending on your interpretation".  To the extent that it's useful in 
some cases of non-repudiation and not others, there should be an 
explanation of which cases it helps and how.

> The timestamp and including the destination identity adds the ability
> to further validate that there wasn’t someone illegitimate that
> simply replayed the sending of the token.

My understanding is that a replay attack is quite different from 
non-repudiation protection.  So the text should not conflate the two.

> replaced with: 'non-repudiation the author of the token, their
> authority to author the token and, minimally, the asserted
> originating identity or persona contained within the token
> corresponding specifically to the originator of personal
> communications'

My guess is that all of the above fall under authentication, not 
non-repuduation.  If my guess is wrong, it really would help to see a 
careful explanation of how it is non-repudiation rather than authentication.

>>> token that cryptographically verifies an originating identity,
>>> or more generally a URI or application specific identity string
>>

So this seems like a good place to raise this basic question:  I thought 
all of the strings that were to be used at 'identity' strings started as 
URIs, albeit with some variations on the type of URI.

Also, there is the continuing point that has been repeatedly stressed 
that STIR's current goal is telephone numbers, not other forms of 
addressing.

>>> communications can also be attached to the token.  The primary
>>> goal of PASSporT is to provide a common framework for signing
>>> persona
>>

Normally, when extensibility is permitted, a base document like this 
defines the extensibility mechanism and might or might not /also/ give 
an initial set of extensions.

(In which case, these really are 'options' and not 'extensions', but 
yes, that's just quibbling...)

In any event, the reference should point to where the extensions or 
extensibility mechanism are specified.

>>> [I-D.ietf-stir-rfc4474bis] provides details of how to use
>>> PASSporT within SIP signaling for the signing and verification of
>>> telephone numbers.
>>
>> remove Note.  Or make it a note to RFC Editor to remove it, or
>> rephrase so it's useful 10 years from now.
>

Why?  It's an uplink reference.  This is a component system used by 
rfc4474bism.  So the uplink confuses the relationship and messes with 
the clean, subsystem interface.

>> Anyhow, this section seems to take the construct of 'token' as
>> being an established term of art.  It isn't.  Or, at least, I've no
>> idea what is meant here that distinguishes a token from anything
>> else, such as other forms of encapsulation.  Say/cite what a token
>> is, if it is such a distinctive thing.  Say/cite how it differs
>> from alternatives, if its superiority is going to be touted.
>>
>>
>>> repudiation and other use cases.  JSON Web Token (JWT) [RFC7519]
>>> and JSON Web Signature (JWS) [RFC7515] are designed to provide a
>>> compact form for many of these purposes and define a specific
>>> method and syntax for signing a specific set of information or
>>> "claims" within the token and therefore providing an extensible
>>> set of claims. Additionally, JWS provides extensible mechanisms
>>> for specifying the method and cryptographic algorithms used for
>>> the associated digital signatures.
>>
>> Note that there is nothing in the above text that actually explains
>> what a token is or how it differs from things that aren't tokens.
>
> I would challenge the fact that ‘token’ is a term of art, but i
> suppose maybe it depends on what crowd you run with.  In either case,
> I defined it as a canonical string object at the beginning of the
> document.

If it is not a term of art, then what does it mean and why is it used? 
That is, it is used here as if it has distinctive meaning -- even at the 
level of being part of a section title! -- but the meaning isn't provided.

>>> As defined in JWS, the "x5u" header parameter is used to provide
>>> a URI [RFC3986] referring to the resource for the X.509 public
>>> key certificate or certificate chain [RFC5280] corresponding to
>>> the key
>>
>> So this service uses a classic X.509 authentication hierarchy?
>> That's a key design point, only mentioned in a third-level
>> section.
>
>>> used to digitally sign the JWS.  Note: The definition of what the
>>> URI represents in terms of the actor serving the X.509 public key
>>> is out
>>
>>> of scope of this document.  However, generally this would
>>> correspond to an HTTPS or DNSSEC resource with the guidance that
>>> it MUST be a
>>
>> [a] remove
>
> fixed
>
>>
>> This /object/ specification (that is transport independent)
>> dictates /transport/ security???  This is probably wrong, but at
>> least needs careful explanation.
>>
>
> This is mostly a comment towards security consideration
> recommendation.  I could remove the comment if it’s bothering folks.

For specification of a discrete component like this, which should be 
entirely independent of lower-level transport, etc. issues, I think the 
legitimate concern is noting that nature of sensitive information is 
carries and the need to protect that information 'appropriate', but to 
treat or state that the details of that protection are outside the scope 
of this specification.

>> When something like this is imported from another spec, there needs
>> to be a precise pointer to the specific part of the spec defining
>> it.
>
> This was the text provided by Ted based on discussion in Berlin, but
> beyond that i’m not seeing what isn’t specific enough.

iat - rfc7519, section 4.1.6, as I noted.

etc.

In other words, try to never require the reader to search around an 
entire document for the information being imported or referenced.

>> 'personal'?  so this can't be used by and between companies?
>> Really, there is nothing about any of this that pertains to the
>> type of users or even the content of the communication.
>
>> What is the exact definition or origination and destination?  For
>> example, there is an important distinction between the person
>> making a call vs. the device they are using, versus the provider
>> they are going through.  Which is meant here and how is the reader
>> to know? (cf, call for a terminology section.)
>
> we don’t want to make the distinction here, it’s only about the
> identity, URI or TN.  whether device or network.  we don’t want to
> predetermine what the end to end architecture is, this is protocol
> only.

origination and destinction are extremely important terms of art for 
STIR and for this specification.  if they have no meaning, don't use 
them.  if they have to be used, they need to be carefully defined, 
either here or in a cited document.

>>> the key represents an identity type and the value is the
>>> identity string.  Currently, these identities can be represented
>>> as either
>>
>>> definition of how telephone numbers or URIs and examples are
>>> provided below.
>>>
>>> The "orig" JSON object MUST only have one key value pair
>>> representing the asserted identity of any type (currently either
>>> "tn" or "uri") of the originator of the personal communications
>>> signaling.
>>>
>>> The "dest" JSON object MUST have at least have one key value
>>> pair, but could have multiple identity types (i.e. "tn" and/or
>>> "uri") but only one of each.  Additionaly, in the case of "dest"
>>> only, the identity type key value MUST be an array signaled by
>>> standard JSON brackets, even when there is a single identity
>>> value in the identity type key value.
>>>

My personal style is to try to have at most 3 levels, with the table of 
contents showing only the first two.  OVerall it seems to be cleaner, 
but yeas, that's purely a matter of taste (although there are also some 
human factors cognitive loading issues when there are more than 3 levels 
in a structure...)

(Re-)organzing things to fit that model sometimes requires creativity.

But since you asked...

  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.  PASSporT Token Overview . . . . . . . . . . . . . . . . . . .   3

  3.  PASSporT Header . . . . . . . . . . . . . . . . . . . . .   4
        3.1.1.  "typ" (Type) Header Parameter . . . . . . . . . . . .   4
        3.1.2.  "alg" (Algorithm) Header Parameter  . . . . . . . . .   4
        3.1.3.  "x5u" (X.509 URL) Header Parameter  . . . . . . . . .   4
  4  PASSporT Payload  . . . . . . . . . . . . . . . . . . . .   5
        3.2.1.  JWT defined claims  . . . . . . . . . . . . . . . . .   5
          3.2.1.1.  "iat" - Issued At claim . . . . . . . . . . . . .   5
        3.2.2.  PASSporT specific claims  . . . . . . . . . . . . . .   5
          3.2.2.1.  Originating and Destination Identity Claims . . .   5
          3.2.2.2.  "mky" - Media Key claim . . . . . . . . . . . . .   7
      3.3.  PASSporT Signature  . . . . . . . . . . . . . . . . . . .   8
  5.  Extending PASSporT  . . . . . . . . . . . . . . . . . . . . .   8
      4.1.  "ppt" (PASSporT) header parameter . . . . . . . . . . . .   8
      4.2.  Extended PASSporT Claims  . . . . . . . . . . . . . . . .   9
  6.  Deterministic JSON Serialization  . . . . . . . . . . . . . .   9
      5.1.  Example PASSport deterministic JSON form  . . . . . . . .  10
  7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
      6.1.  Avoidance of replay and cut and paste attacks . . . . . .  10
      6.2.  Solution Considerations . . . . . . . . . . . . . . . . .  10
      6.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  11

For deeper subsections, consider converting them to a labeled hanging 
indent.  This especially works when there's already a convenient label, 
like 'iat'.

Lots of small subsections tends to break up the reading.  Hanging 
indents don't.

>>>
>>> If the originating or destination identity is a telephone number,
>>> the key representing the identity should be "tn".
>>
>>> Telephone Number strings for "tn" MUST be canonicalized according
>>> to the procedures specified in [I-D.ietf-stir-rfc4474bis] Section
>>> 7.2.
>>
>> Given that the phone number construct is at the core of the work
>> here and this is the essential data object, and this object is
>> presumably intended for use outside of 4474bis, I'd expect that
>> canonicalization algorithm to be here.
>>
>> If 4474 needs to cite/use the algorithm, it can cite here, which it
>> already will have to do.  There is no other normative use of 4474
>> in this document.
>>
>
> needs discussion

oh goodie.

>>> If any of the originating or destination identities is of the
>>> form URI, as defined in [RFC3986], the key representing the
>>> identity should be "uri" URI form of the identity.
>>
>>> { "dest":{"uri":["sip:[email-masked]"]}, "iat":"1443208345",
>>> "orig":{"tn":"12155551212"} }
>>>
>>> { "dest":{ "tn":["12125551212"], "uri":["sip:[email-masked]",
>>> "sip:[email-masked]"] }, "iat":"1443208345",
>>> "orig":{"tn":"12155551212"} }
>>>
>>> Some protocols that use PASSporT convey hashes for media
>>> security keys within their signaling in order to bind those keys
>>> to the identities established in the signaling layers.  One
>>> example would be the DTLS-SRTP key fingerprints carried in SDP
>>> via the "a=fingerprint" attribute; multiple instances of that
>>> fingerprint may appear in a single SDP body corresponding to
>>> difference media streams offered.
>>
>> difference -> different?
>>
>> The above text belongs elsewhere, explaining the overall set of
>> capabilities, use cases, and the like  In a definitions section
>> like this, focus on definitions, not discussions about use.
>>

Well, I fear it's a relatively esoteric reference, so that it probably 
needs to assume less familiarity by the reader, which is to say the 
example needs to explain itself more.

>>> the base set of claims from this document, the order in which
>>> they will appear, and any further information necessary to
>>> implement the extension.  All extensions MUST incorporate the
>>> baseline JWT elements specified in Section 3; claims may only be
>>> appended to the claims
>>
>> This seems best and first handled by earlier in the spec, by
>> providing a syntax (and text) that shows the base set and then an
>> optional extended set.  With that setup, it is clear that
>> extensions are always /in addition to/ the base.
>
> JSON sort of provides this capability inherently, so would prefer to
> keep it simple rather than adding more protocol.

The 'sort of' does not encourage confidence about the resolution of this 
point...

>> The JSON object MUST follow the rules for the construction of
>>> the thumbprint of a JSON Web Key (JWK) as defined in [RFC7638]
>>> Section 3. Each JSON object MUST contain no whitespace or line
>>> breaks before or after any syntactic elements and with the
>>> required members ordered lexicographically by the Unicode
>>> [UNICODE] code points of the member names.
>>
>> mumble.
>
> ?

I was reacting the to the redundant specification here, as well as to 
its being in prose that gets a bit complicated.  (Humans process 
negation and discussion worse than conjunction.)

Basically, this spec should not be repeated technical details that are 
being specified elsewhere and used here.  They should be be reference.

>> Perhaps explain the steps followed to produce this? Perhaps show
>> the intermediate forms?
>>
>
> will discuss the need for more explicit instructions, to me, it’s
> following the spec, but could improve if folks think it’s necessary.

I think the main concern I was expressing was that it should a result, 
without commentary, and without showing the intermediate steps.  As 
such, the reader learns relatively little from the example, IMO.

>>> for avoidance of replay and cut and paste attacks.  PASSporT
>>> tokens must be sent along with other application level protocol
>>> information
>>
>>> (e.g. for SIP an INVITE as defined in [RFC3261]).  There should
>>> be a link between various information provided in the token and
>> The semantics of iat are defined earlier. Either there is
>> compliance or there isn't. The discussion here, therefore, should
>> probably say something like "a valid iat claim aids in detecting
>> re-use at a later time.”
>
>> What is a delta time?  How is the reader to know?  Where is it
>> defined? I suspect what is meant is that it's deviation from time
>> of origination should be small.  If this has a more precise
>> technical definition, then cite it.
>
> removed delta
>
>>
>>
>>> characteristics associated with the application using the
>>> PASSporT token.
>>>
>>> It should be recognized that the use of this token should not,
>>> in it's own right, be considered a full solution for absolute
>>> non- repudiation of the persona being asserted.  This only
>>> provides non- repudiation of the signer of PASSporT.  If the
>>> signer and the persona
>>
> This is only a statement to recognize that you are only trusting the
> signer and certificate owner to tell the truth about the originating
> identity.  If you are familiar with how certificates work, this is an
> obvious statement, but just a word of consideration.

Start by saying the affirmative, so that the negative has a foundation.

For the current topic, the usual caveat language is along the lines that 
"authentication validates authorization to use the identifier, but does 
not imply any assessment about the reputation or safety of the actor 
using the identifier"  or somesuch...

While authentication does involve a kind of trust, using that word here 
usually confuses readers that it it has something to do with 'usage 
reputation' that is the derivative function after authentication.

>>> telecommunications networks today, protecting the destination
>>> party from being spoofed may take some interpretation or
>>> additional verification of the link between the PASSporT
>>> signature and the persona being asserted.
>>>
>>> In addition, the telecommunications systems and specifications
>>> that use PASSporT should in practice provide mechanisms for:
>>>
>>> o  Managing X.509 certificates and X.509 certificate chains to
>>> an authorized trust anchor that can be a trusted entity to all
>> specifications devoted to X.509. Just cite them and don't attempt
>> to repeat them.
>
> I see this as helpful, we can discuss if it’s not needed, but I
> recall being asked by working group to include text to inform the
> reader.
>
>>
>>> o  Accounting for entities that may route calls from other peer
>>> or interconnected telecommunications networks that are not part
>>> of the "trusted" communications network or may not be following
>>> the usage of PASSporT or the profile of PASSporT appropriate to
>>> that network
>>

While some of my comments in this subsection can be class as matters of 
taste or an opinion about risks of redundant text, this here point is 
about language that is simply wrong.

>> On the other hand, perhaps this qualifies for a discussion about
>> transferring passport objects across administrative (trust) domain
>> boundaries?
>>
>> At best, this section seems to be trying to compensate for the lack
>> of a framework discussion about the problem domain and the
>> practical uses of the various specifications being produced.
>
> similar to above comment, this is meant to be a cautionary statement
> and something to consider if you are an implementer.  If you
> understand the limits of what X.509 based certificate signing and PKI
> can represent in terms of trust, these are obvious statements, but I
> think it’s good to include none-the-less.

In other words, you are trying to provide a tutorial about X.509 rather 
than discussion about Passport.

d/
-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Aug 2016 16:52:42 -0700

On Sat, Aug 27, 2016 at 2:40 PM, Dave Crocker <[email-masked]> wrote:

> That seems to equate authentication with non-reputation of originator. But
> they aren't the same.
>

Do you mean "non-repudiation" here? I ask because "reputation" is also a
concept potentially in play here.

> careful explanation of how it is non-repudiation rather than authentication.

I think it would probably be fine to remove the term "non-repudiation" from
this spec, since it only appears in the abstract. Generally, it's not that
useful a concept for most security settings, especially when one starts to
ask questions about the legal context.

With that said, given that these tokens are signed by their creator and
there is a timestamp to provide anti-replay, there is at least potentially
an important technical property being provided here, which is that in the
case where a passport creator signs a bogus passport, it is possible to
demonstrate that it did so, which is not a property necessarily provided by
authentication systems.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Aug 2016 17:07:32 -0700

On 8/27/2016 4:52 PM, Eric Rescorla wrote:
>
>
> On Sat, Aug 27, 2016 at 2:40 PM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:

>     That seems to equate authentication with non-reputation of
>     originator. But they aren't the same.
>
>

I'm using 'non-repudiation' because the spec uses that term.

If the spec really means 'reputation', that opens a different set of 
concerns, since nothing in any of the 3 documents has to do with 
reputation, per se.

> I think it would probably be fine to remove the term "non-repudiation"
> from this spec, since it only appears in the abstract. Generally, it's
> not that useful a concept for most security settings, especially when
> one starts to ask questions about the legal context.
>
> there is a timestamp to provide anti-replay, there is at least
> potentially an important technical property being provided here, which
> is that in the case where a passport creator signs a bogus passport, it
> is possible to demonstrate that it did so, which is not a property
> necessarily provided by authentication systems.

And I believe that was my original guess, although my very limited 
understanding of non-repudiation includes the significant burden of 
having the timestamp, itself, be validated by an independent authority. 
Otherwise, the signer could claim any time they want to...

d/

-- 

   Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Aug 2016 17:19:43 -0700

> concerns, since nothing in any of the 3 documents has to do with

Just checking.

> understanding of non-repudiation includes the significant burden of having
> the timestamp, itself, be validated by an independent authority. Otherwise,
> the signer could claim any time they want to...

That doesn't seem correct to me, at least if "independent" means someone
other than the relying party. The signature is itself a proof attaching the
signer's private key to the passport and to a claim by the signer about the
passport object's assertions being valid at the time in the timestamp. If
the relying party checks the timestamp and rejects it if it has a bogus
timestamp, then any acceptable passport will be relatively fresh and thus
will be usable as a proof of the signer's representation at the relevant
time. Overall, this seems less important than the freshness property wrt
authentication, but it's still a technical property.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Aug 2016 18:46:02 -0700

On 8/27/2016 5:19 PM, Eric Rescorla wrote:
>     having the timestamp, itself, be validated by an independent
>     authority. Otherwise, the signer could claim any time they want to...
>
>
> other than the relying party. The signature is itself a proof attaching
> the signer's private key to the passport and to a claim by the signer
> about the passport object's assertions being valid at the time in the
> timestamp. If the relying party checks the timestamp and rejects it if
> it has a bogus timestamp, then any acceptable passport will be
> relatively fresh and thus will be usable as a proof of the signer's
> representation at the relevant time. Overall, this seems less important
> than the freshness property wrt authentication, but it's still a
> technical property.

This sounds pretty much the same as authentication.

While the verifier might decide that the timestamp is ok, if the 
verification is close enough in time to that claimed occurrence, it does 
nothing for being able to prove the timing to a third-party, /later/. 
And that's the environment I'm used to hearing about needing 
'non-repudiation' for.

In that case, the timestamp needs to have validation that is independent 
of the signer.  What I'm used to hearing, for that, is that an 
independent timestamp service does a kind of notary signature on the 
original signer's stuff, including the timestamp.

Anyhow, all of seems to go beyond STIR's needs, suggesting that it would 
be best to remove use of the term?

d/

-- 

   Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Aug 2016 18:54:00 -0700

> nothing for being able to prove the timing to a third-party, /later/.

Well, what you can prove (at any time in the future) is that the signer
claimed that a given thing was true at (what it claimed was) a given time.
You can prove this to a third party.

This isn't a necessary property of authentication. For instance, the
relying party could share a key with the passport generator and the
passport could be secured with a MAC.

> of the signer.  What I'm used to hearing, for that, is that an independent
> timestamp service does a kind of notary signature on the original signer's
> stuff, including the timestamp.
>

I'm not sure why you think non-repudiation needs a notary signature. That's
not generally the case, as indicated above, and even if you do have a
timestamping service, all it can prove is that the signature was generated
*prior* to a given time, not at a given time.

Anyhow, all of seems to go beyond STIR's needs, suggesting that it would be
> best to remove use of the term?

Yes, I think that would be fine.

---

From: Michael Hammer <[email-masked]>
Date: Sun, 28 Aug 2016 15:41:58 +0000

Ummm….

If any signature can be repudiated by the sender, 

then how do you apply any consequences for bad behavior?

Any caller could just say, it wasn’t me and they are off the hook?

Isn’t the consequence tree:

-          Not signed:  customer may not answer or caveat emptor

-          Signed, robocall:  crackdown

-          Signed, normal call:  good to go?

I assume that a signed call that has faulty credentials, 

e.g. bad timestamp, unknown signer, could get filtered out.

But, that gets into carrier policy that can’t be standardized.

Michael Hammer

[email-masked] <mailto:[email-masked]> 

+1 408 202 9291

© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

From: stir [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Saturday, August 27, 2016 9:54 PM
To: Dave Crocker <[email-masked]>
Cc: Chris Wendt <[email-masked]>; [email-masked]
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

On Sat, Aug 27, 2016 at 6:46 PM, Dave Crocker <[email-masked] <mailto:[email-masked]> > wrote:

While the verifier might decide that the timestamp is ok, if the verification is close enough in time to that claimed occurrence, it does nothing for being able to prove the timing to a third-party, /later/.

Well, what you can prove (at any time in the future) is that the signer claimed that a given thing was true at (what it claimed was) a given time. You can prove this to a third party.

This isn't a necessary property of authentication. For instance, the relying party could share a key with the passport generator and the passport could be secured with a MAC.

And that's the environment I'm used to hearing about needing 'non-repudiation' for.

In that case, the timestamp needs to have validation that is independent of the signer.  What I'm used to hearing, for that, is that an independent timestamp service does a kind of notary signature on the original signer's stuff, including the timestamp.

I'm not sure why you think non-repudiation needs a notary signature. That's not generally the case, as indicated above, and even if you do have a timestamping service, all it can prove is that the signature was generated *prior* to a given time, not at a given time.

Anyhow, all of seems to go beyond STIR's needs, suggesting that it would be best to remove use of the term?

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net <http://bbiw.net>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Aug 2016 09:21:09 -0700

> Any caller could just say, it wasn’t me and they are off the hook?

I don't think I said that. It certainly wasn't what I meant.

> But, that gets into carrier policy that can’t be standardized.

Yes, this is correct.

-Ekr

> *________________________________*
>
> *Michael Hammer*
>
> [email-masked]
>
> +1 408 202 9291
>
>
> © 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality
> notice. This message is private and confidential. If you have received this
> message in error, please notify us and remove it from your system.
>
>
>
> *From:* stir [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Saturday, August 27, 2016 9:54 PM
> *To:* Dave Crocker <[email-masked]>
> *Cc:* Chris Wendt <[email-masked]>; [email-masked]
> *Subject:* Re: [stir] Review of: draft-ietf-stir-passport-05
>
>
>
>
>
>
>
> I'm not sure why you think non-repudiation needs a notary signature.
> That's not generally the case, as indicated above, and even if you do have
> a timestamping service, all it can prove is that the signature was
> generated *prior* to a given time, not at a given time.
>
>
>
>
>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 29 Aug 2016 14:52:03 -0400

Agree, will remove term “non-repudiation", discussed this in ATIS Task Force and came to realization that we are looking at the Passport representing purely an assertion of the identity and the signer is the party responsible for that assertion, and “buyer beware”.

> On Aug 27, 2016, at 8:07 PM, Dave Crocker <[email-masked]> wrote:
> 
> If the spec really means 'reputation', that opens a different set of concerns, since nothing in any of the 3 documents has to do with reputation, per se.
> 
> 
> And I believe that was my original guess, although my very limited understanding of non-repudiation includes the significant burden of having the timestamp, itself, be validated by an independent authority. Otherwise, the signer could claim any time they want to...
> 
> d/
> 
> 
> -- 
> 
>  Dave Crocker

---

From: Alex Bobotek <[email-masked]>
Date: Mon, 29 Aug 2016 11:50:11 -0700

The realization below also necessitates changes to the first sentence of the abstract and a scrub of the body of the document wrt  to verifying the originating identity.  This verification is optional.  

Regards,

Alex

> From: stir [mailto:[email-masked]] On Behalf Of Chris Wendt
> Sent: Monday, August 29, 2016 11:52 AM
> Cc: [email-masked]; Eric Rescorla <[email-masked]>
> Agree, will remove term "non-repudiation", discussed this in ATIS Task Force
> and came to realization that we are looking at the Passport representing
> purely an assertion of the identity and the signer is the party responsible for
> that assertion, and "buyer beware".
> 
> 
> >> Do you mean "non-repudiation" here? I ask because "reputation" is
> >> also a concept potentially in play here.
> >
> > If the spec really means 'reputation', that opens a different set of concerns,
> since nothing in any of the 3 documents has to do with reputation, per se.
> >
> >
> >> from this spec, since it only appears in the abstract. Generally,
> >> it's not that useful a concept for most security settings, especially
> >> when one starts to ask questions about the legal context.
> >>
> >> With that said, given that these tokens are signed by their creator
> >> and there is a timestamp to provide anti-replay, there is at least
> >> potentially an important technical property being provided here,
> >> which is that in the case where a passport creator signs a bogus
> >> passport, it is possible to demonstrate that it did so, which is not
> >> a property necessarily provided by authentication systems.
> >

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Aug 2016 21:12:30 +0100

On 29/08/16 19:52, Chris Wendt wrote:
>  will remove term “non-repudiation",

Almost always a good change to a protocol specification IMO:-)

S.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Aug 2016 13:15:03 -0700

> Almost always a good change to a protocol specification IMO:-)

Bold statement.  But will anyone repudiate it?

d/

-- 

   Dave Crocker