Re: [stir] Separation of JWS

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

I asked some people about this at the IETF today, but I'm still not clear (and I am not sure RFC7515 is clear) if the intention of Appendix F is to omit both the headers and claims or just the claims. I'll continue asking around about it - the ambiguity is about what the "payload" there means exactly.

I will say though that 4474bis is being implemented by a number of people at this point and I haven't heard this particular problem raised before. I don't think it is unclear what you're supposed to do with "canon". We can argue what is most optimal, but I hesitate to make yet another syntax change for the sake of something that doesn't really change the semantics. The spec doesn't need to be further delayed for purely cosmetic reasons.

Frustratingly, I suspect that this is just a question of syntax, and that at the end of the day it sounds like we're trying to get to the same place. Sometimes it is hardest to choose between options when the differences are the slightest.

Jon Peterson
Neustar, Inc.

Sent from my iPad

On Jul 16, 2016, at 10:00 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

I am commenting with an implementer hat on, and I don’t think we should accept what we have now. In my opinion there would be interop issues from day one, because 1) we are “splitting” the encoded JWS string into different pieces, and 2) it is not clear how the encoding of that will look like.

My suggestion is to send the whole encoded PassPORT JWS object string as the Identity header field value, according to the JWS standard, and drop the “canon” header field parameter. That was my assumption since the day we adopted JWS. I still allows not sending the claims in a standard manner. I also don’t think it should be allowed to drop the mandatory JWS headers.

Doing the change in the draft should not be a big task.

Regards,

Christer



From: Richard Shockey [mailto:[e-mail]]
Sent: 16 July 2016 13:29
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>; Peterson, Jon <[e-mail]<mailto:[e-mail]>>
Cc: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>
Subject: Re: [stir] Separation of JWS


Christer if you are frustrated I certainly understand.

As I have read through v10 here I’m wondering how it can be successfully implemented by the vendor community.  There is clearly strong, in fact overwhelming demand to implement this but the last thing we need are the kinds of baked in interoperability problems we have seen in VoLTE, for instance.  I can assure you the NRA’s have been told we have a solution but we realistically need to give them some implementation timelines.

The lack of actual full examples of a typical originating INVITE, is appalling.  I have serious questions whether this document is ready for adoption.

Should we just accept what we have now?  Should the SIP Forum immediately look into some ongoing profile work here as we start down this road?   I know Robert would like to see some examples of implementations at SIPit but is there enough time given the ongoing questions the document does not answer.



—
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 [phone]


From: stir <[e-mail]<mailto:[e-mail]>> on behalf of Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 15, 2016 at 5:35 PM
To: "Peterson, Jon" <[e-mail]<mailto:[e-mail]>>
Cc: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>
Subject: Re: [stir] Separation of JWS

Hi,

>Oh, you meant Appendix F of RFC7515. I had thought you said RFC7315 in your other mail, so perhaps you can understand my confusion.

Sorry :)

>My reading of that is that it can remove the claims but not the header. But it's also not super specific about how it works.

What do you think is unclear?

I am using it for a draft I’m working on, and I think it’s pretty clear :)

I am also not sure why we should remove the headers. Don’t we need that information?

>5.2.1 of rfc4474bis-10 contains the crispest statement of the syntax of canon, perhaps, but it is not the job of rfc4474bis to repeat the guidance of
>PASSporT on how to construct the object. Perhaps a pointer to that specific section of PASSporT would help?

My question is not how to construct the object, but how to construct the “canon” header field value, which seems to be only a part of the object string.

Section 5.2.1 describes which components (headers and claims) are used to create the “canon” value, but now HOW it’s created.

So, I’d like to suggest that we transport the PASSportT object string as the Identity header field value, and don’t use “canon”. I am happy to hear why we can’t do that, but so far I have not heard/read anything :)

That would also allow people to use off-the-shelf JWS encoders/decoders, and we would avoid the confusion of transporting different parts of the object string in different places.

Regards,

Christer


On Jul 15, 2016, at 2:09 AM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

> This is partly the same question as we are exploring in the "syntax change" thread discussion on whether or not "canon" will always be included.

It’s not really the same. My question is: *IF* the claims are included, why do we put them in a separate place (the “canon” header field parameter)? Why don’t we use the standard JWS mechanism?

>To answer your question, think about it as if SIP does not carry a JWS object, but instead it transports some data that allows a verification service
>to generate a JWS object. So we're not "sending" the JWS object, and thus we're under no obligation to "send it as one string" or whatever.
>
>The rfc4474bis "canon" parameter optionally contains the encoded portion of the header and claims of the JWS object because the headers (and claims) in baseline PASSporT are usually redundant wth the contents of >a SIP request - we anticipate that any verification service can ordinarily regenerate those headers and claims itself, so, there's no ostensible value in carrying them. Generally speaking, we should bloating messages >with redundant fields if we can.

I agree. But, Appendix F describes how to do that with JWS.

>If you're asking why we chose to demarcate that with "canon" rather than just not including the JWS header and claims if we didn't
>want to include the JWS header and claims, it is generally better to be explicit than to leave the verification service to infer what is going.

In my opinion it’s better to follow the standard. And, again, Appendix F describes how to not included the claims in a standard way.

Also, I am not sure (need to verify) whether it’s allowed to remove all headers.

Also, *IF* we want to use the “canon” header field parameter, the draft doesn’t give enough information on how it is generated.

We have the following syntax in Section 8:

canonical-str = "canon" EQUAL *base64-char

…and, in a few places of the document we have text like:

“The syntax of "canon" is given in Section 8; essentially, it contains a base64
              encoding of the JSON header and claims in the PASSporT object.”

But, I cannot find text on how that base64-char string is generated. You have the base64 encoding of the JSON header, and the base64 encoding of the claims. How do you combine them into the base64 encoded “canon” value?

Regards,

Christer

_______________________________________________ stir mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/stir