Subject: Re: [stir] Double Quotes (ppt="shaken")

From: "Zerr, Brad" <[email-masked]>
Date: Mon, 12 Apr 2021 13:25:28 +0000

Hi All,

I wanted to follow up on this request to gather feedback.

From: Zerr, Brad
Sent: Friday, April 9, 2021 8:30 AM
To: IETF STIR Mail List <[email-masked]>
Cc: Maier, Rudy <[email-masked]>; Toy, Arthur <[email-masked]>
Subject: Double Quotes (ppt="shaken")

RFC 8224 defines the Identity header field for SIP.  It uses the PASSporT token as a basis for creation of the Identity header field in SIP INVITE messages.

Can you confirm that the "parameter" ppt MUST have double quotes around shaken?

Example

Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmN

lciJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxMjEyNTU1MTIxMyJdfSwiaWF0IjoxNDcxMzc1NDE4LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTI

ifSwib3JpZ2lkIjoiMTIzZTQ1NjctZTg5Yi0xMmQzLWE0NTYtNDI2NjU1NDQwMDAwIn0._V41ThRJ74MktxeLGaZQGAi
r8pcIvmB6OQEMgS4Ym7FPwGxm3tDUTRTpQ5X0relYsetEScb9otFNDxOCTjergeyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cDov
L2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydCJ9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiIxNDcxMzc1NDE4Iiwib3J
pZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6nY4MvmK5JKHZH9hSYkWI4g75m
nq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtCA ;info=https://cert.example.org/passport.cerhttp://cert.example2.net/example.cert<https://cert.example.org/passport.cerhttp:/cert.example2.net/example.cert>;ppt="shaken" ;alg=ES256

Brad Zerr | Sr. Sales Engineer, Communications Market
Transaction Network Services
7311 W 132nd Street | Suite 300 | Overland Park | KS 66213 | USA
 +1 913 488 2335 |    [email-masked]<mailto:[email-masked]> |    www.tnsi.com<http://www.tnsi.com/>

________________________________

This e-mail message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorized reviews, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply e-mail and destroy all copies
of the original message.
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Apr 2021 15:02:06 +0000

Hi Brad,

As you may see, there is an ongoing discussion on the list regarding ppt quotes :)

The issue is that the syntax in RFC 8224 does NOT define usage of quotes. However, the ATIS specification, and some PASSPort extension RFCs, DO use quotes in examples.

As far as I know, the WG DID make a decision some time ago that quotes ARE used.

Regards,

Christer

From: stir <[email-masked]> On Behalf Of Zerr, Brad
Sent: maanantai 12. huhtikuuta 2021 16.25
To: IETF STIR Mail List <[email-masked]>
Cc: Maier, Rudy <[email-masked]>; Toy, Arthur <[email-masked]>
Subject: Re: [stir] Double Quotes (ppt="shaken")

Hi All,

From: Zerr, Brad
Sent: Friday, April 9, 2021 8:30 AM
To: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Cc: Maier, Rudy <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
Subject: Double Quotes (ppt="shaken")

Can you confirm that the “parameter” ppt MUST have double quotes around shaken?

Example

nq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtCA ;info=https://cert.example.org/passport.cerhttp://cert.example2.net/example.cert<https://protect2.fireeye.com/v1/url?k=ea8eb30a-b5158a0f-ea8ef391-86959e472243-bbf4a1be3eae340e&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=https%3A%2F%2Fcert.example.org%2Fpassport.cerhttp%3A%2Fcert.example2.net%2Fexample.cert>;ppt=”shaken" ;alg=ES256

Brad Zerr | Sr. Sales Engineer, Communications Market
Transaction Network Services
7311 W 132nd Street | Suite 300 | Overland Park | KS 66213 | USA
 +1 913 488 2335 |    [email-masked]<mailto:[email-masked]> |    www.tnsi.com<https://protect2.fireeye.com/v1/url?k=a71e45d8-f8857cdd-a71e0543-86959e472243-a0e4c12e7774bb3f&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http%3A%2F%2Fwww.tnsi.com%2F>

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com<https://protect2.fireeye.com/v1/url?k=91792a99-cee2139c-91796a02-86959e472243-1f1a1d528c7eb151&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http%3A%2F%2Fwww.mimecast.com%2F>
________________________________

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 11:39:22 -0400

Hi All,

Regarding quotes around the ptt value, we now have RFC  8224 grammar saying
one thing and workgroup decision regarding examples in RFC saying the
opposite.

I want to ask the chairs to raise this question for the group:

Should we fix the examples in group RFCs so that they do not include quotes
around the ppt header value, or should we update the grammar in RFC 8224?

This issue affects the current deployments of STIR/SHAKEN, which are under
tight deadlines due to federal regulation, and needs an urgent resolution.

Thank You,
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 11:03 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> The issue is that the syntax in RFC 8224 does NOT define usage of quotes.
> However, the ATIS specification, and some PASSPort extension RFCs, DO use
> quotes in examples.
>
>
>
> *From:* stir <[email-masked]> *On Behalf Of *Zerr, Brad
> *Sent:* maanantai 12. huhtikuuta 2021 16.25
> *To:* IETF STIR Mail List <[email-masked]>
> *Cc:* Maier, Rudy <[email-masked]>; Toy, Arthur <[email-masked]>
> *Subject:* Re: [stir] Double Quotes (ppt="shaken")
>
>
>
> Hi All,
>
>
>
> *From:* Zerr, Brad
> *Sent:* Friday, April 9, 2021 8:30 AM
> *To:* IETF STIR Mail List <[email-masked]>
> *Cc:* Maier, Rudy <[email-masked]>; Toy, Arthur <[email-masked]>
> *Subject:* Double Quotes (ppt="shaken")
>
>
>
> RFC 8224 defines the Identity header field for SIP.  It uses the PASSporT
> token as a basis for creation of the Identity header field in SIP INVITE
> messages.
>
>
>
> Identity:
> eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmN
>
>
> nq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtCA ;info=
> https://cert.example.org/passport.cerhttp://cert.example2.net/example.cert
> <https://protect2.fireeye.com/v1/url?k=ea8eb30a-b5158a0f-ea8ef391-86959e472243-bbf4a1be3eae340e&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=https%3A%2F%2Fcert.example.org%2Fpassport.cerhttp%3A%2Fcert.example2.net%2Fexample.cert>
> ;ppt=”shaken" ;alg=ES256
>
>
>
>
>
>
>
> *Brad Zerr *| Sr. Sales Engineer, Communications Market
>
>  +1 913 488 2335 |    [email-masked] |   www.tnsi.com
> <https://protect2.fireeye.com/v1/url?k=a71e45d8-f8857cdd-a71e0543-86959e472243-a0e4c12e7774bb3f&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http%3A%2F%2Fwww.tnsi.com%2F>
>
>
>
>
> ------------------------------
>
>
> ------------------------------
>
> <https://protect2.fireeye.com/v1/url?k=91792a99-cee2139c-91796a02-86959e472243-1f1a1d528c7eb151&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http%3A%2F%2Fwww.mimecast.com%2F>
> ------------------------------
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 12 Apr 2021 08:59:42 -0700

> around the ppt header value, or should we update the grammar in RFC 8224?

I also would like this question asked again.  Thanks.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Apr 2021 15:40:21 -0400

We will discuss this topic at the STIR virtual interim planned for Wednesday.

I wonder if the best way forward is to tell implementers that both quoted and non-quoted should be accepted by verification services; however quotes is the recommendation for senders.

Russ

> On Apr 12, 2021, at 11:59 AM, Marc Petit-Huguenin <[email-masked]> wrote:
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 15:52:43 -0400

Quotes are wrong for multiple reasons:

1. This is against the RFC 8224, which defines this header
2. It is a waste of two bytes
3. It implies that ppt value is case-sensitive

The best recommendation is to ignore the ppt value in the header if full
form identity is used and send non-quoted.
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 3:40 PM Russ Housley <[email-masked]> wrote:

> I wonder if the best way forward is to tell implementers that both quoted
> and non-quoted should be accepted by verification services; however quotes
> is the recommendation for senders.
>
> Russ
>
>
> <
> https://protect2.fireeye.com/v1/url?k=ea8eb30a-b5158a0f-ea8ef391-86959e472243-bbf4a1be3eae340e&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=https%3A%2F%2Fcert.example.org%2Fpassport.cerhttp%3A%2Fcert.example2.net%2Fexample.cert
> >
> ;ppt=”shaken" ;alg=ES256
>
>
>
>
>
>
>
> <
> https://protect2.fireeye.com/v1/url?k=a71e45d8-f8857cdd-a71e0543-86959e472243-a0e4c12e7774bb3f&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http%3A%2F%2Fwww.tnsi.com%2F
> >
>
>
>
>
> <
> https://protect2.fireeye.com/v1/url?k=91792a99-cee2139c-91796a02-86959e472243-1f1a1d528c7eb151&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http%3A%2F%2Fwww.mimecast.com%2F
> >
> Email: [email-masked] <[email-masked]>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 12 Apr 2021 19:59:52 +0000

We've tried to settle this in the past:

https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/stir/?q=ppt*20quoted__;JQ!!N14HnBHF!vMYZ-cuVEYSBv2woRQgojIeurho6uo_dTEHrWR_Lyk_HYp9mWhEbzTcKoDM$ 

... and the result was a general agreement that ppt must be quoted. Tolga at the time suggested that we have a backwards compatibility clause for implementers; basically, saying that you should be prepared to accept either, but you should send quoted. I personally only care that we agree on what way it is supposed to be.

So basically, I'm fine with RFC8224 errata that fixes the ABNF grammar to quoted. Anecdotally, is anyone aware of an implementation today that only accepts unquoted?

Jon Peterson
Neustar, Inc.

On 4/12/21, 9:00 AM, "stir on behalf of Marc Petit-Huguenin" <[email-masked] on behalf of [email-masked]> wrote:

    
    >> https://urldefense.com/v3/__https://cert.example.org/passport.cerhttp:/*cert.example2.net/example.cert__;Lw!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJsCsthHzA$ 
    >> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=ea8eb30a-b5158a0f-ea8ef391-86959e472243-bbf4a1be3eae340e&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=https*3A*2F*2Fcert.example.org*2Fpassport.cerhttp*3A*2Fcert.example2.net*2Fexample.cert__;JSUlJSUlJQ!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJshyWQNRQ$ >
    >> ;ppt=”shaken" ;alg=ES256
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >>   +1 913 488 2335 |    [email-masked] |   https://urldefense.com/v3/__http://www.tnsi.com__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJv5yr3Hgg$ 
    >> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=a71e45d8-f8857cdd-a71e0543-86959e472243-a0e4c12e7774bb3f&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http*3A*2F*2Fwww.tnsi.com*2F__;JSUlJQ!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuzHfeiTg$ >
    >>
    >>
    >>
    >>
    >> For more information please visit https://urldefense.com/v3/__http://www.mimecast.com__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuF1PeJPg$ 
    >> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=91792a99-cee2139c-91796a02-86959e472243-1f1a1d528c7eb151&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuveQxklA$ >
    >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJt92J0AmQ$ 
    >>
    > 
    > 
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJt92J0AmQ$ 
    > 

    -- 
    Marc Petit-Huguenin
    Email: [email-masked]
    Blog: https://urldefense.com/v3/__https://marc.petit-huguenin.org__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJvikmpacw$ 
    Profile: https://urldefense.com/v3/__https://www.linkedin.com/in/petithug__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuMHTP0MA$ 
    
    _______________________________________________
    stir mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJt92J0AmQ$

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 12 Apr 2021 13:29:05 -0700

On 4/12/21 12:59 PM, Peterson, Jon wrote:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/stir/?q=ppt*20quoted__;JQ!!N14HnBHF!sbZbiloMy9_i8DFOGKM-hf5cVpkTkuhnkxloKpwUYqxGGTmGoUY-MtYKHYaXnn83Tl0$
> 

As people tend to test an implementation with itself (a puzzling thing IMO), I think it will take some time before the problem becomes visible.

On the other hand there is existing implementations that send with quotes and implementations that send without.  Roman sent a list, and I know of two that also send unquoted:

https://mailarchive.ietf.org/arch/msg/stir/95Th3Yd26OpTrzWc4EatxTO_h20/

So IMO we should:

- Revert the ABNF in the errata in RFC 8224, and add some text somewhere saying that parser should be tolerant to quotes around the token in that case (Postel's Principle), but still treat it as token (for case sensitivity purpose).
- Fill an erratum for each RFC that uses quotes.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 17:19:07 -0400

Jon,

Just for the record, the decision to quote ppt values was done during IETF
101, after RFC8224 was published. This would make this change an update and
not an errata.

Does anyone remember the reason why the group made the decision to quote
this value?
Is there any reason why ppt value should be case sensitive or include
characters not allowed in the token?
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 4:00 PM Peterson, Jon <[email-masked]>
wrote:

> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/stir/?q=ppt*20quoted__;JQ!!N14HnBHF!sRfbVWLP11xlDkZicIXZWUz2n9d8GM-NdnBHRp6H_dfjTo8EUe8Uiju2xDXpBA$
>
> ... and the result was a general agreement that ppt must be quoted. Tolga
> at the time suggested that we have a backwards compatibility clause for
> implementers; basically, saying that you should be prepared to accept
> either, but you should send quoted. I personally only care that we agree on
> what way it is supposed to be.
>
> So basically, I'm fine with RFC8224 errata that fixes the ABNF grammar to
> quoted. Anecdotally, is anyone aware of an implementation today that only
> accepts unquoted?
>
> Jon Peterson
> Neustar, Inc.
>
> On 4/12/21, 9:00 AM, "stir on behalf of Marc Petit-Huguenin" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     >> As you may see, there is an ongoing discussion on the list
> regarding ppt
>     >> quotes :)
>     >>
>     >>
>     >>
>     >> As far as I know, the WG DID make a decision some time ago that
> quotes ARE
>     >> used.
>     >>
>     >>
>     >>
>     >> Regards,
>     >>
>     >>
>     >>
>     >> Christer
>     >>
>     >>
>     >>
>     >> Can you confirm that the “parameter” ppt MUST have double quotes
> around
>     >> shaken?
>     >>
>     >>
>     >>
>     >> Example
>     >>
>     >>
>     >>
>     >> Identity:
>     >>
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=ea8eb30a-b5158a0f-ea8ef391-86959e472243-bbf4a1be3eae340e&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=https*3A*2F*2Fcert.example.org*2Fpassport.cerhttp*3A*2Fcert.example2.net*2Fexample.cert__;JSUlJSUlJQ!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJshyWQNRQ$
> >
>     >> ;ppt=”shaken" ;alg=ES256
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>   +1 913 488 2335 |    [email-masked] |
> https://urldefense.com/v3/__http://www.tnsi.com__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJv5yr3Hgg$
>     >> <
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=a71e45d8-f8857cdd-a71e0543-86959e472243-a0e4c12e7774bb3f&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http*3A*2F*2Fwww.tnsi.com*2F__;JSUlJQ!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuzHfeiTg$
> >
>     >>
>     >>
>     >>
>     >>
>     >> This e-mail message is for the sole use of the intended
> recipient(s) and
>     >> may
>     >> contain confidential and privileged information of Transaction
> Network
>     >> Services.
>     >> Any unauthorized reviews, use, disclosure or distribution is
> prohibited.
>     >> If you are not
>     >> the intended recipient, please contact the sender by reply e-mail
> and
>     >> destroy all copies
>     >> of the original message.
>     >>
>     >> This email has been scanned for email related threats and delivered
> safely
>     >> by Mimecast.
>     >> For more information please visit
> https://urldefense.com/v3/__http://www.mimecast.com__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuF1PeJPg$
>     >> <
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=91792a99-cee2139c-91796a02-86959e472243-1f1a1d528c7eb151&q=1&e=8e0dc536-8d5c-4493-b0e4-ef5e1dba07f2&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuveQxklA$
> >
>     Blog:
> https://urldefense.com/v3/__https://marc.petit-huguenin.org__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJvikmpacw$
>     Profile:
> https://urldefense.com/v3/__https://www.linkedin.com/in/petithug__;!!N14HnBHF!qy0Tc_vSEcOU08-_TXlTcFehhHv85wk_mP2ljjNKtjrVI8Dd83kyuCfWzikslJuMHTP0MA$
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 12 Apr 2021 21:28:58 +0000

I disagree. There is MUST-strength normative text in RFC8224 that says you are supposed to quote the values. The issue here is a discrepancy between that text and the ABNF, not a post-facto decision made after RFC8224 was published. I was just pointing out that this discussion is rehashing one we already tried to have.

The decision to resolve the discrepancy by quoting came down to simple pragmatism, the question of which precedents were being followed by subsequent standardization and implementation. The record just needs to be set straight, this is not a technical decision anyone needs to agonize over. On balance, I agree with Marc that we just need some Postel-principle guidance on receiving, and more firm guidance on sending. Which is why I’m curious how many implementations are not feeling very Postel about the matter.

Jon Peterson
Neustar, Inc.

From: Roman Shpount <[email-masked]>
Date: Monday, April 12, 2021 at 2:19 PM
To: "Peterson, Jon" <[email-masked]>
Cc: Marc Petit-Huguenin <[email-masked]>, Robert Sparks <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>, IETF STIR Mail List <[email-masked]>, "Zerr, Brad" <[email-masked]>, "Maier, Rudy" <[email-masked]>, "Toy, Arthur" <[email-masked]>
Subject: Re: [stir] Double Quotes (ppt="shaken")

Jon,

Just for the record, the decision to quote ppt values was done during IETF 101, after RFC8224 was published. This would make this change an update and not an errata.

Does anyone remember the reason why the group made the decision to quote this value?
Is there any reason why ppt value should be case sensitive or include characters not allowed in the token?
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 17:36:33 -0400

Jon,

Can you point me to the text in RFC8224 that says that quoted values should
be supported?
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 5:29 PM Peterson, Jon <[email-masked]>
wrote:

>
>
> I disagree. There is MUST-strength normative text in RFC8224 that says you
> are supposed to quote the values. The issue here is a discrepancy between
> that text and the ABNF, not a post-facto decision made after RFC8224 was
> published. I was just pointing out that this discussion is rehashing one we
> already tried to have.
>
>
>
> The decision to resolve the discrepancy by quoting came down to simple
> pragmatism, the question of which precedents were being followed by
> subsequent standardization and implementation. The record just needs to be
> set straight, this is not a technical decision anyone needs to agonize
> over. On balance, I agree with Marc that we just need some Postel-principle
> guidance on receiving, and more firm guidance on sending. Which is why I’m
> curious how many implementations are not feeling very Postel about the
> matter.
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *Roman Shpount <[email-masked]>
> *Date: *Monday, April 12, 2021 at 2:19 PM
> *To: *"Peterson, Jon" <[email-masked]>
> *Cc: *Marc Petit-Huguenin <[email-masked]>, Robert Sparks <
> [email-masked]>, Russ Housley <[email-masked]>, Christer
> Holmberg <[email-masked]>, IETF STIR Mail List <
> [email-masked]>, "Zerr, Brad" <[email-masked]>, "Maier, Rudy" <
> [email-masked]>, "Toy, Arthur" <[email-masked]>
> *Subject: *Re: [stir] Double Quotes (ppt="shaken")
>
>
>
> Jon,
>
>
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 12 Apr 2021 21:42:48 +0000

4.1: Fourth, if a PASSporT extension is in use, then the optional JSON
      key "ppt" MUST be present and have a value equivalent to the
      quoted value of the "ppt" parameter of the Identity header field.

I believe this was already cited earlier in the thread(s), but it is the “quoted value” part there that has been read as a normative strength endorsement. It is saying directly that the value in the Identity header field is quoted.

Jon Peterson
Neustar, Inc.

Date: Monday, April 12, 2021 at 2:36 PM

Jon,

Can you point me to the text in RFC8224 that says that quoted values should be supported?
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 5:29 PM Peterson, Jon <[email-masked]> wrote:

Jon Peterson
Neustar, Inc.

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 12, 2021 at 2:19 PM
To: "Peterson, Jon" <[email-masked]>
Cc: Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>, Robert Sparks <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>, "Zerr, Brad" <[email-masked]<mailto:[email-masked]>>, "Maier, Rudy" <[email-masked]<mailto:[email-masked]>>, "Toy, Arthur" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Double Quotes (ppt="shaken")

Jon,

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 18:44:38 -0400

Jon,

On Mon, Apr 12, 2021 at 5:43 PM Peterson, Jon <[email-masked]>
wrote:

> I believe this was already cited earlier in the thread(s), but it is the
> “quoted value” part there that has been read as a normative strength
> endorsement. It is saying directly that the value in the Identity header
> field is quoted.
>
>
>
As far as I can see, this language does not say anything about the ppt
value in the SIP Identity header. This entire section specifies how
the PASSporT header JSON object is composed, not the SIP Identity header.
All this language is specifying is that the ppt parameter in the header
JSON object must be present and set to the quoted value of the SIP Identity
header field.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Apr 2021 07:10:44 +0000

Hi Roman,

...

> As far as I can see, this language does not say anything about the ppt value in the SIP Identity header. This entire section specifies how the PASSporT header JSON object is composed, not the SIP Identity header. All this language is specifying
> is that the ppt parameter in the header JSON object must be present and set to the quoted value of the SIP Identity header field.

I agree.

Because, if you read the bullets in Section 4.1, "quoted" is only used when the corresponding value is quoted in a SIP header field (kind of, as describe below)

For example, the text of the 3rd bullet says;

   "o  Third, the JSON key "x5u" MUST have a value equivalent to the
      quoted URI in the "info" parameter, per the simple string
      comparison rules of [RFC3986], Section 6.2.1."

The URI is quoted in "info" parameter of the SIP Identity header field.

The text of the 5th and 6th bullets say:

      "then the array MUST be populated with a JSON object containing a "tn" element with a
      value set to the value of the quoted originating identity"

      "then the array MUST be populated with a JSON object containing a "tn" element with a
      value set to the value of the quoted destination identity"

(Now, SIP To and From URIs actually don't have to be quoted (sometimes they have to be), but let's leave that for now.)

I think the confusion comes from the usage of "quoted" in the text. Is the purpose to point out that the corresponding value is quoted in SIP (which, IMHO, is irrelevant), or that the value is quoted is quoted in SIP and therefor also in the PASSporT?

It is also worth noting that in SIP the values are quoted using left- and right angle quotes, but you are not copying those quotes into the PASSporT.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Apr 2021 07:16:45 +0000

(I pressed SEND too early.)

Now, in addition to what I said below, the bullet for "ppt" says:

   "o  Fourth, if a PASSporT extension is in use, then the optional JSON
      key "ppt" MUST be present and have a value equivalent to the
      quoted value of the "ppt" parameter of the Identity header field."

And, THIS is what I think is the main source of confusion. 

Because, as described earlier, "quoted" seems to be used when the corresponding value is quoted in SIP. Now, that would mean that the "ppt" value *is* also quoted in SIP.
Regards,

Christer

-----Original Message-----
From: stir <[email-masked]> On Behalf Of Christer Holmberg
Sent: tiistai 13. huhtikuuta 2021 10.11
To: Roman Shpount <[email-masked]>; Peterson, Jon <[email-masked]>
Cc: Maier, Rudy <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; Russ Housley <[email-masked]>; IETF STIR Mail List <[email-masked]>; Toy, Arthur <[email-masked]>; Zerr, Brad <[email-masked]>; Robert Sparks <[email-masked]>
Subject: Re: [stir] Double Quotes (ppt="shaken")

Hi Roman,

...

> value in the SIP Identity header. This entire section specifies how the PASSporT header JSON object is composed, not the SIP Identity header. All this language is specifying is that the ppt parameter in the header JSON object must be present and set to the quoted value of the SIP Identity header field.

I agree.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2021 23:59:23 -0400

On Tue, Apr 13, 2021 at 3:16 AM Christer Holmberg <
[email-masked]> wrote:

> Because, as described earlier, "quoted" seems to be used when the
> corresponding value is quoted in SIP. Now, that would mean that the "ppt"
> value *is* also quoted in SIP.
>

This seems like a very round-about explanation. Considering that this
section is talking about how the JWT PASSporT header is generated, it is
strange that it should be considered normative for the SIP header formation.

Even if the document specifies two opposite things, we should probably pick
the one that makes sense. Quoting a value that is always a token makes
little sense. Unless this document wants to imply that the ppt value is a
quoted string and should always be case sensitive, I see no reason why
quotes are required. In either case, some errata needs to apply either to
this section or to the grammar to avoid future confusion.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Apr 2021 07:15:24 +0000

Hi,

> This seems like a very round-about explanation. Considering that this section is talking about how the JWT PASSporT header is generated, it is strange that it
> should be considered normative for the SIP header formation.

I agree with you, but that seems to be the way the text is written: "quoted" is used whenever the corresponding value is quoted in SIP.

Again, in my opinion, from a PASSporT perspective it is irrelevant whether a value is quoted in SIP or not.

Regards,

Christer