Re: [stir] [EXTERNAL] Re: PASSPorT: "orig" and "dest" mandatory in all PASSPorTs?

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

I certainly hope that the semantics are basically the same, yes, that the
only real difference is in how nested "div" is carried in the signaling.
The main reason for embedding right now is forward compatibility with OOB,
correct. If we ever decided we wanted to be able to encrypt PASSporTs
carried in-band, this would also be very handy. In general it seems like
kind of a nuisance to hand a verification service a pile of Identity
headers and say "you figure out what goes with what" - when I started
pondering cases with spirals in signaling, for example, I got a little
worried.

The next revision to the document is going to talk a bit about an issue
that has arisen in implementation (already) with the Diversion header and
3xx responses. There probably should be a means for a 3xx to carry a
nested PASSporT in the response that could be tucked into an Identity
header by any entity sending new INVITEs based on the Contacts in the 3xx
- but there are a few potential pitfalls there we need to avoid, or at
least carefully mark.

Jon Peterson
Neustar, Inc.

On 1/26/18, 9:27 AM, "stir on behalf of Julio Martinez-Minguito"
<[e-mail] on behalf of [e-mail]>
wrote:

>Hi,
>
>I see in the nested divert that the new PASSporT has a claim "opt" which
>includes the PASSporT of the originating network, including the
>signature. 
>The PASSporT added by the diverting network includes a claim "orig",
>which is copied from the 'original' PASSporT.
>In this case , for a PASSporT ppt:div, the diverting network mays not
>have authority over the claim "orig", but only over the claim 'div'. A
>verifier will have to check the embedded PASSporT, verify the signature
>and check that the orig in the different PASSporT matches.
>
>Though in another cases, if the originating number and the diverting are
>served by the same operator, the operator has authority over both orig
>and div claims. A nested PASSporT would not be needed in this case.
>
>The end result is quite similar as if we have multiple Identity headers.
>In the end there are multiple PASSporT objects, the difference is how
>they are conveyed in the signaling.
>
>I assume the main reason for the embedding is because of the oob
>solution, or?
>
>Regards, Julio
>
>> -----Original Message-----
>> From: Christer Holmberg [mailto:[e-mail]]
>> Sent: den 24 januari 2018 15:06
>> To: Chris Wendt <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [stir] PASSPorT: "orig" and "dest" mandatory in all
>>PASSPorTs?
>> 
>> Hi,
>> 
>> >I guess i¹m not following what¹s not clear, if you MUST only have one
>> >orig claim and one identity in that claim, that seems to be pretty
>> >clear to me that you cannot either not have an orig claim or have more
>> >than one.  I guess maybe i¹m missing something subtle in your point.
>> 
>> It is clear that you cannot have more than one claim, but I think it
>>could be
>> made more clear that you always must have a claim to begin with :)
>> 
>> >For extensions, and in general with any PASSporT, once the PASSporT is
>> >signed, that¹s it, you cannot modify claims or "re-sign".  If you want
>> >new PASSporT claim information that you want to sign, you must have a
>> >new PASSporT or new identity header.
>> 
>> Correct, I should have made that clear.
>> 
>> So, if you have two (or more) Identity header fields, do they all have
>>to
>> contain the same ³orig² value? Or, is one allowed to change it?
>> 
>> Does the same apply for ³dest²? And, if you want to change the ³dest²
>>you
>> need to use the divert extension? You can¹t just add a new passport
>>with a
>> new ³dest² value. Or?
>> 
>> >Currently for divert, the approach is to embed a PASSporT inside a new
>> >PASSporT, which is a valid technique also and result in a new identity
>> >header also (but you should remove the old identity header in this
>>case).
>> 
>> My colleague Julio sent some questions and issues regarding the
>> ³embedding²/³nesting² approach. I would be happy if you look at those :)
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> >
>> >-Chris
>> >
>> >> On Jan 23, 2018, at 2:19 PM, Christer Holmberg
>> >><[e-mail]> wrote:
>> >>
>> >> Hi Chris,
>> >>
>> >>>> Question for clarification:
>> >>>>
>> >>>> Section 5.2.1 of draft-passport says:
>> >>>>
>> >>>>      "There MUST be exactly one "orig" claim with exactly one
>> >>>>identity claim object in a PASSporT object."
>> >>>>
>> >>>> Q1: Does the text above mean that
>> >>>>
>> >>>>      a) a passport must always contain one, one only one, "orig"
>> >>>>claim; or
>> >>>>      b) that if a passport contains an "orig" claim, if can only
>> >>>>contains one?
>> >>>
>> >>> It can only contain one key value pair with the key ³orig² and the
>> >>>claim value can only be one identity.
>> >>>
>> >>> In other words you cannot claim to originate multiple identities
>> >>>with a single passport object.
>> >>
>> >> Correct. The question is whether "orig" is mandatory (alternative a)
>> >>or not (alternative b). But, based on your reply to Q2 below, I assume
>> >>the answer is alternative a).
>> >>
>> >> I think it would be good to make that more clear.
>> >>
>> >>>> Q2: If a), does it apply to passport extensions too?
>> >>>
>> >>> All extensions must include the base passport claims and follow all
>> >>>rules of the claims, so yes.
>> >>
>> >> I think it should be more clear whether a node can modify claims or
>> >>not when adding an extension, or whether an extension needs to
>> >>explicitly allow it. Currently the text only says (AFAIK) that claims
>> >>cannot be removed.
>> >>
>> >> For example, if I have a base passport, and add an RPH passport, I
>> >>assume I cannot change the value of the "dest" claim. I would need to
>> >>use a divert claim for that.
>> >>
>> >> Also, as the passports may be added and signed by different
>> >>authorities, and as each passport will contain the base claims, it
>> >>means that the base claims will be signed multiple times, and they may
>> >>be signed by different authorities. I assume that is ok.
>> >>
>> >> Regards,
>> >>
>> >> Christer
>> >>
>> >
>> 
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_stir&d=DwIFAw&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weX
>HNMl9xZnnsIiwRd6IgY&m=CYEKQetxoYJFWkCYlTjULI4cuXYtswc-ksgANHWODz0&s=n8n5Xn
>LoHH1N9qVTNdWCn5VNUcQIQMajN21qTivbnD8&e=