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

[Chris Wendt <[e-mail]>]

HI Dave,

Thanks again for the comments, i have submitted 07 version of draft that incorporates the fixes and modifications hopefully addressing most of your feedback.

The new draft also provides other private comments i have received as well.

Thanks!

-Chris

> On Aug 27, 2016, at 5:40 PM, Dave Crocker <[e-mail]> wrote:
> 
> 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
> ...
>>> 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.
> 
> 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.

Removed non-repudiation from the overview, the solution consideration also reinforces the point that only the signer can be verified, not the claims.

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

agree, addressed above

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

agreed, addressed above

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

Yes, but i think the consensus is that it wouldn’t be a bad thing to be compatible with SIP URIs at a minimum, and have a framework that could be accommodated in the future if necessary.

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

provided a section reference

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

I changed this from a Note to a explicit reference, hopefully that covers your concern.

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

Sorry i phrased my last comment incorrectly, I DO believe it is a term of art, but in either case i specifically defined it.

> 
> 
>>>> 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.
> 
> 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.
> 
> 
changed to "Generally, as defined in JWS section 4.1.5, this would correspond to an HTTPS or DNSSEC resource using integrity protection."

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

ok, got it, i think i did update those references, or at least they seem to have section references into the documents.

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

Modified this paragraph to be the following: 
PASSporT defines claims that convey the identity of the origination and destination of personal communications.  Origination in the context of PASSporT and for a given application’s use of PASSporT is the point in the network that has the authority to assert the callers identity.  This authority is represented in PASSporT by the certificate holder and is signed at the applications choice of authoritative point(s) in the network, for example, at a device that has authenticated with a user, or at a network entity with an authenticated trust relationship with that device and it's user.  Destination represents the intended destination of the personal communications, i.e. the identity(s) being called by the caller, The destination point(s) determined by the application must have the capability to verify the PASSporT token and the digital signature. The PASSporT associated certificate is used to validate the authority of the originating signer, generally via a certificate chain to the trust anchor for that application.   

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

Have for the most part followed your suggestion, thanks.

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

Some discussion has happened between authors and Working Group chairs on this.  Considered new draft specifically for telephone number canonicalization, but given time and practicalities of imposing this pretty disruptive change at this point, the current conclusion was to continue to reference 4474bis as a default definition of telephone number canonicalization for SIP for STIR.

> 
> 
> 
>>>> 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:[e-mail]"]}, "iat":"1443208345",
>>>> "orig":{"tn":"12155551212"} }
>>>> 
>>>> Single Originator to Multiple Destination Identities example:
>>>> 
>>>> { "dest":{ "tn":["12125551212"], "uri":["sip:[e-mail]",
>>>> "sip:[e-mail]"] }, "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.
> 
> 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.

Removed DTLS-SRTP reference and replaced with a citing a reference to a=fingerprint definition in rfc4572#section-5 which i think covers things better anyway.

> 
> 
> 
>>>> 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.
> 
> The 'sort of' does not encourage confidence about the resolution of this point…
> 

added basic example, we could also point to draft-peterson-stir-cnam-00 as a specific example

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

Agree, fixed the reference to be more accurate without repeating text.

> 
> 
>>>> 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:[e-mail]"],"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.
> 
> 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.

Expanded the example with steps of construction of the final object.

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

Tried to clarify things and incorporate relevant considerations i removed based on next comment.

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

text is redundant and removed the bullets.

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

same comment as above.

> 
> 
> 
> 
> d/
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> 
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net