Subject: [stir] Proposal for update of erratum #6519

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 18 Apr 2021 08:55:11 -0700

As discussed during the interim meeting, here's my proposal for the new text of erratum #6519.  Note that "Original Text" and "Corrected Text" refer to the names of the erratum fields, not to the current content:

- Original Text:

Section 4 says:

   ident-type = "ppt" EQUAL token

- Corrected Text:

It should say:

   ident-type = "ppt" EQUAL (token / LDQUOTE token RDQUOTE)

Furthermore in the second paragraph of section 4, the following sentence should be inserted after 'defines the optional "ppt" parameter (PASSporT Type).':

   Implementations SHOULD use quotes around the token when sending and be tolerant to the absence of quotes when receiving.

Similarly in the fourth bullet of the first list in section 4.1, the sentence '...a value equivalent to the quoted value of the "ppt" parameter...' is replaced by:

   ...a quoted value whose unquoted part is equivalent to the token in the "ppt" parameter...

Finally in the first paragraph of section 9, the sentence '...The "ppt" parameter value MUST consist of a token...' is replaced by:

   ...The "ppt" parameter value MUST consist of a token (between quotes)...

- Notes:

Based on discussions in the STIR WG, implementations should use the quoted form when sending, but should accept both forms when receiving.  Regardless of the presence of the quotes, the content is treated as a token, i.e. is case-insensitive as explained in RFC 3261 section 7.3.1.  Note also that the new syntax does not allow for spaces immediately before or immediately after the token when quoted.

-- 
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: Sun, 18 Apr 2021 13:00:49 -0400

Should this be as follows?

   ident-type = "ppt" EQUAL ( token / ( LDQUOT token RDQUOT ) )

Russ

> On Apr 18, 2021, at 11:55 AM, Marc Petit-Huguenin <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 18 Apr 2021 10:12:38 -0700

>     ident-type = "ppt" EQUAL ( token / ( LDQUOT token RDQUOT ) )

Yes, thanks.  Mix-up between DQUOTE and LDQUOT/RDQUOT.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2021 16:48:48 +0000

Hi,

A few comments:

Q1: Instead of talking about "being tolerant", we say that an implementation MUST accept values with or without quotes.

---

Q2: Regarding the following statement:

"Note also that the new syntax does not allow for spaces immediately before or immediately after the token when quoted."

That is wrong. The syntax DOES allow it.

And, why does it bother if there are spaces?

Regards,

Christer

________________________________
From: stir <[email-masked]> on behalf of Marc Petit-Huguenin <[email-masked]>
Sent: Sunday, April 18, 2021 6:55 PM
To: [email-masked] Mail List <[email-masked]>
Subject: [stir] Proposal for update of erratum #6519

- Original Text:

Section 4 says:

- Corrected Text:

It should say:

- Notes:

--
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=f3adc327-ac36fa25-f3ad83bc-869a14f4b08c-93577bad37148e54&q=1&e=6560ca76-961e-422e-be46-b21dbd7d45d2&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 19 Apr 2021 11:23:34 -0700

Hi,

Responses inline.

> Q1: Instead of talking about "being tolerant", we say that an implementation MUST accept values with or without quotes.

That would place "with" or "without" quote on equal status, which they do not have.

> That is wrong. The syntax DOES allow it.

No, it does not.  Let's expand it:

ident-type = "ppt" EQUAL (token / ( SWS DQUOTE token DQUOTE SWS ))

The SWS are possible outside the quotes, but not inside.

> And, why does it bother if there are spaces?

Because now you need to explain that the spaces needs to be removed, before comparing the values.

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Apr 2021 14:36:07 -0400

> ident-type = "ppt" EQUAL (token / ( SWS DQUOTE token DQUOTE SWS ))

SWS allows CRLF.  Is that allowed in a claim?  If so, I thought that LDQUOT is defined as SWS DQUOTE, and RDQUOT is defined as DQUOTE SWS.

If we are going to take this approach, we need to allow white space before EQUAL, and we also need it for the unquoted token.

Russ

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 19 Apr 2021 12:25:45 -0700

On 4/19/21 11:36 AM, Russ Housley wrote:
> SWS allows CRLF.  Is that allowed in a claim?  

No, but that's why I said 'a quoted value whose unquoted part is equivalent to the token in the "ppt" parameter'.  All these are the same claim ('\' used to wrap)

ppt=test
ppt=TeST
ppt="test"
ppt="TeST"
ppt = test
ppt = "test"
ppt \
   = \
     "teSt"

These are different claims than above:

ppt=" test"
ppt="test "
ppt="test
ppt=test"
ppt = "\
   test"
ppt = "test\
  "

> If so, I thought that LDQUOT is defined as SWS DQUOTE, and RDQUOT is defined as DQUOTE SWS.
> 

EQUAL is SWS "=" SWS, so no need.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Apr 2021 18:06:18 -0400

On Mon, Apr 19, 2021 at 3:26 PM Marc Petit-Huguenin <[email-masked]>
wrote:

> No, but that's why I said 'a quoted value whose unquoted part is
> equivalent to the token in the "ppt" parameter'.  All these are the same
> claim ('\' used to wrap)
>
> ppt=test
> ppt=TeST
> ppt="test"
> ppt="TeST"
> ppt = test
> ppt = "test"
> ppt \
>    = \
>      "teSt"
>
> > If we are going to take this approach, we need to allow white space
> before EQUAL, and we also need it for the unquoted token.
>

If we define ident-type = "ppt" EQUAL ( token / ( LDQUOT token RDQUOT ) )
then
ppt=" test"
ppt="test "
ppt="test
ppt=test"
ppt = "\
   test"
ppt = "test\
  "
are all invalid. A token cannot contain a space. Both quotes are required
if either is present.

Also, I thought the group decision was endpoints MUST accept ppt value as a
token with or without quotes. Endpoints MUST send a token in quotes. I have
explicitly asked if the group wanted SHOULD in either place, and the
preference was for the MUST level requirements. I think the errata should
say this unless there is a good reason to change it.

Best Regards,
_____________
Roman Shpount

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 19 Apr 2021 16:56:14 -0700

> are all invalid. A token cannot contain a space. Both quotes are required

A literalist.  Fantastic.

Now, can we go back to fix that text ?

> say this unless there is a good reason to change it.

That was not my understanding.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Apr 2021 21:57:06 -0400

> A literalist.  Fantastic.

I did not know we are supposed to judge this errata on artistic merits.

This is exactly what I am doing.

My understanding was that grammar was defined as ident-type = "ppt" EQUAL (
token / ( LDQUOT token RDQUOT ) ) explicitly to avoid these sorts of
issues. I agree with your note that the new syntax does not allow for
spaces immediately before or immediately after the token when quoted and I
think it should be present in the errata. I also think that we should add a
note that even though the ppt value is case insensitive, a normalized
version as defined in
https://www.iana.org/assignments/passport/passport.xhtml (or all lower case
version) should be used when constructing a JWT header.

> That was not my understanding.

We can go back to the recording to check on the decision.

More importantly, what is the normative strength of "be tolerant to the
absence of quotes when receiving"? Is this MUST accept quotes? SHOULD
accept quotes?

In the sentence "Implementations SHOULD use quotes around the token when
sending", what would be the valid use cases when implementations are
allowed not to use quotes?

My understanding is that SHOULD implies well know exceptions.

Best Regards,
_____________
Roman Shpount

---

From: Russ Housley <[email-masked]>
Date: Tue, 20 Apr 2021 09:21:55 -0400

> On Apr 19, 2021, at 9:57 PM, Roman Shpount <[email-masked]> wrote:
> 

Since RDQUOT allows whitespace after the double quote, do we need to allow whitespace after token when there are no quotes?

    ident-type = "ppt" EQUAL ( ( token SWS ) / ( LDQUOT token RDQUOT ) )

Russ

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 10:20:33 -0400

Hi Russ,

The complete grammar would be:

      Identity = "Identity" HCOLON signed-identity-digest SEMI
          ident-info *( SEMI ident-info-params )
      signed-identity-digest = 1*(base64url-char / ".")
      ident-info = "info" EQUAL ident-info-uri
      ident-info-uri = LAQUOT absoluteURI RAQUOT
      ident-info-params = ident-info-alg / ident-type /
          ident-info-extension
      ident-info-alg = "alg" EQUAL token
      ident-type =  "ppt" EQUAL ( token / ( LDQUOT token RDQUOT ) )
      ident-info-extension = generic-param

base64url-char = ALPHA / DIGIT / "-" / "_"

In this grammar, SEMI is defined as SEMI = SWS ";" SWS. This should take
care of the SWS after the token.
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 9:22 AM Russ Housley <[email-masked]> wrote:

> Since RDQUOT allows whitespace after the double quote, do we need to allow
> whitespace after token when there are no quotes?
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 20 Apr 2021 14:46:25 +0000

Inline.

From: stir <[email-masked]> on behalf of Roman Shpount <[email-masked]>
Date: Monday, April 19, 2021 at 6:57 PM
To: Marc Petit-Huguenin <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

On Mon, Apr 19, 2021 at 7:56 PM Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>> wrote:
A literalist.  Fantastic.

More importantly, what is the normative strength of "be tolerant to the absence of quotes when receiving"? Is this MUST accept quotes? SHOULD accept quotes?

In the sentence "Implementations SHOULD use quotes around the token when sending", what would be the valid use cases when implementations are allowed not to use quotes?

The exception we are aware of is that implementations exhibiting this behavior exist. It is, in other words, for backwards compatibility reasons.

Regardless of what the recording says (we were kinda all over the place, if I recall), I think I agree that the right semantics are that you MUST accept quoted and unquoted, and SHOUD send quotes (the exception to the SHOULD being backwards compatibility). If we said you MUST send quotes, well, then implementations that don’t are violating the spec. As you pointed out, it’s kind of a mixed bag at the moment out there in terms of where implementations are.

Jon Peterson
Neustar, Inc.

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 20 Apr 2021 14:58:58 +0000

Is it really a problem to just say that you must (or must not, either way) include quotes and be done? STI-AS and STI-VS implementations will need to be updated frequently over the next few years due to all of the new PASSporT extensions, so expecting implementations to add/remove quotes seems reasonable. Implementations could accept both values at their discretion, even if it violates the standard.

Sincerely,

Alec Fenichel

Senior Software Architect

[email-masked]

+1 (407) 760-0036

TransNexus

From: stir <[email-masked]> on behalf of Peterson, Jon <jon.peterson=[email-masked]>
Date: Tuesday, April 20, 2021 at 10:47
To: Roman Shpount <[email-masked]>, Marc Petit-Huguenin <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Inline.

On Mon, Apr 19, 2021 at 7:56 PM Marc Petit-Huguenin <[email-masked]> wrote:

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 20 Apr 2021 15:05:15 +0000

I mean, no, it’s just pushy. It’s the same reason we don’t propose that you MUST only accept quoted. Given that it was the ambiguity in the original spec that caused this problem, I’m a little hesitant to be that pushy.

Maybe for the errata we could be less pushy, but when we (inevitably, someday) do an actual update or bis to RFC8224, we could be more pushy about it.

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]> on behalf of Alec Fenichel <alec.fenichel=[email-masked]>
Date: Tuesday, April 20, 2021 at 7:59 AM
To: "Peterson, Jon" <jon.peterson=[email-masked]>, Roman Shpount <[email-masked]>, Marc Petit-Huguenin <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Sincerely,

Alec Fenichel

Inline.

Jon Peterson
Neustar, Inc.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 11:06:06 -0400

On Tue, Apr 20, 2021 at 10:46 AM Peterson, Jon <[email-masked]>
wrote:

>
>
> Inline.
>
>
>
> *From: *stir <[email-masked]> on behalf of Roman Shpount <
> [email-masked]>
> *Date: *Monday, April 19, 2021 at 6:57 PM
> *To: *Marc Petit-Huguenin <[email-masked]>
> *Cc: *IETF STIR Mail List <[email-masked]>, Russ Housley <
> [email-masked]>, Christer Holmberg <[email-masked]>
> *Subject: *Re: [stir] Proposal for update of erratum #6519
>
>
>
> The exception we are aware of is that implementations exhibiting this
> behavior exist. It is, in other words, for backwards compatibility reasons.
>
>
>
> Regardless of what the recording says (we were kinda all over the place,
> if I recall), I think I agree that the right semantics are that you MUST
> accept quoted and unquoted, and SHOUD send quotes (the exception to the
> SHOULD being backwards compatibility). If we said you MUST send quotes,
> well, then implementations that don’t are violating the spec. As you
> pointed out, it’s kind of a mixed bag at the moment out there in terms of
> where implementations are.
>
>
>
Then we should say this in the text. Something like:

Implementations SHOULD use quotes around the token when sending and MUST
accept the token with or without the quotes around it. There are existing
implementations of this specification that send the ppt value without the
quotes, and such behavior is allowed for legacy interoperability reasons.

P.S. I know I am in the minority here, but I think values should be sent
without quotes. The main reason is that, in this case, the syntax reflects
the value content. By seeing the value without the quotes in the message,
it is understood that it is a token, spaces and special characters are not
allowed there, and the comparison is not case-sensitive. When the value is
in quotes, there is an assumption that this is a quoted string. Even though
the standard still defines this as a token, an extra step is required when
interpreting the message.

This entire thing reminds me of (sorry for the unrelated quote):

But I was thinking of a plan
To dye one's whiskers green,
And always use so large a fan
That it could not be seen.
_____________
Roman Shpount

---

From: Russ Housley <[email-masked]>
Date: Tue, 20 Apr 2021 11:31:12 -0400

This looks good to me.

> On Apr 20, 2021, at 10:20 AM, Roman Shpount <[email-masked]> wrote:
> 
> Hi Russ,
> 
> In this grammar, SEMI is defined as SEMI = SWS  ";"  SWS. This should take care of the SWS after the token.
> _____________
> Roman Shpount
> 
> 
> On Tue, Apr 20, 2021 at 9:22 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Apr 19, 2021, at 9:57 PM, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 20 Apr 2021 15:31:18 +0000

Jon,

Understood. Then maybe we could just leave it as is until RFC 8224 is updated? Is there any implementation out there that doesn’t support receiving with or without quotes?

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

From: Peterson, Jon <jon.peterson=[email-masked]>
Date: Tuesday, April 20, 2021 at 11:05
To: Alec Fenichel <[email-masked]>, Peterson, Jon <[email-masked]>, Roman Shpount <[email-masked]>, Marc Petit-Huguenin <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Jon Peterson

Neustar, Inc.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Inline.

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 12:02:25 -0400

Alec,

My personal opinion is that we should try to organize an open SipIt interop
event for both STIR and SHAKEN implementations. Based on the interop
results, it might be good to do a new version of RFC 8224.

Meanwhile, we really need this errata so that we can deal with current
interop issues.

Best Regards,
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 11:31 AM Alec Fenichel <[email-masked]>
wrote:

> Jon,
>
>
>
> Understood. Then maybe we could just leave it as is until RFC 8224 is
> updated? Is there any implementation out there that doesn’t support
> receiving with or without quotes?
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> *From: *Peterson, Jon <jon.peterson=[email-masked]>
> *Date: *Tuesday, April 20, 2021 at 11:05
> *To: *Alec Fenichel <[email-masked]>, Peterson, Jon
> <[email-masked]>, Roman Shpount <[email-masked]>, Marc
> Petit-Huguenin <[email-masked]>
> I mean, no, it’s just pushy. It’s the same reason we don’t propose that
> you MUST only accept quoted. Given that it was the ambiguity in the
> original spec that caused this problem, I’m a little hesitant to be that
> pushy.
>
>
>
> Maybe for the errata we could be less pushy, but when we (inevitably,
> someday) do an actual update or bis to RFC8224, we could be more pushy
> about it.
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *stir <[email-masked]> on behalf of Alec Fenichel
> <alec.fenichel=[email-masked]>
> *Date: *Tuesday, April 20, 2021 at 7:59 AM
> *To: *"Peterson, Jon" <jon.peterson=[email-masked]>, Roman
> Shpount <[email-masked]>, Marc Petit-Huguenin <[email-masked]>
> Is it really a problem to just say that you must (or must not, either way)
> include quotes and be done? STI-AS and STI-VS implementations will need to
> be updated frequently over the next few years due to all of the new
> PASSporT extensions, so expecting implementations to add/remove quotes
> seems reasonable. Implementations could accept both values at their
> discretion, even if it violates the standard.
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> *From: *stir <[email-masked]> on behalf of Peterson, Jon
> <jon.peterson=[email-masked]>
> *Date: *Tuesday, April 20, 2021 at 10:47
> *To: *Roman Shpount <[email-masked]>, Marc Petit-Huguenin <
> [email-masked]>

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 20 Apr 2021 16:32:55 +0000

Roman,

Makes sense. I think a new version would be great. Proposed changes:

Require quotes around ppt param value

Make info param optional when using full form PASSporTs to make OOB easier for transit providers

Allow info param to match claims other than x5u (e.g., jku, etc.) to support DLT and other future PASSporT extensions that don’t use x5u

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

From: Roman Shpount <[email-masked]>
Date: Tuesday, April 20, 2021 at 12:02
To: Alec Fenichel <[email-masked]>
Cc: Peterson, Jon <jon.peterson=[email-masked]>, Peterson, Jon <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Alec,

My personal opinion is that we should try to organize an open SipIt interop event for both STIR and SHAKEN implementations. Based on the interop results, it might be good to do a new version of RFC 8224.

Meanwhile, we really need this errata so that we can deal with current interop issues.

Best Regards,

_____________
Roman Shpount

On Tue, Apr 20, 2021 at 11:31 AM Alec Fenichel <[email-masked]> wrote:

Jon,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Jon Peterson

Neustar, Inc.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Inline.

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 20 Apr 2021 16:35:55 +0000

I think we should do an errata for now, along the lines Marc proposed. In the future, we can look at an RFC8224bis, but I don’t think there’s enough to warrant that significant a revision yet.

Jon Peterson
Neustar, Inc.

From: Roman Shpount <[email-masked]>
Date: Tuesday, April 20, 2021 at 9:02 AM
To: Alec Fenichel <[email-masked]>
Cc: "Peterson, Jon" <jon.peterson=[email-masked]>, "Peterson, Jon" <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Alec,

Best Regards,
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 11:31 AM Alec Fenichel <[email-masked]<mailto:[email-masked]>> wrote:
Jon,

Sincerely,

Alec Fenichel
Senior Software Architect
[email-masked]<mailto:[email-masked]>
+1 (407) 760-0036
TransNexus

From: Peterson, Jon <jon.peterson=[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 20, 2021 at 11:05
To: Alec Fenichel <[email-masked]<mailto:[email-masked]>>, Peterson, Jon <[email-masked]>, Roman Shpount <[email-masked]<mailto:[email-masked]>>, Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Proposal for update of erratum #6519

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Alec Fenichel <alec.fenichel=[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 20, 2021 at 7:59 AM
To: "Peterson, Jon" <jon.peterson=[email-masked]<mailto:[email-masked]>>, Roman Shpount <[email-masked]<mailto:[email-masked]>>, Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Proposal for update of erratum #6519

Sincerely,

Alec Fenichel
Senior Software Architect
[email-masked]<mailto:[email-masked]>
+1 (407) 760-0036
TransNexus

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Peterson, Jon <jon.peterson=[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 20, 2021 at 10:47
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>, Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Proposal for update of erratum #6519

Inline.

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 19, 2021 at 6:57 PM
To: Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Proposal for update of erratum #6519

Jon Peterson
Neustar, Inc.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 13:40:04 -0400

Alec,

I would also like to add:

1. The Date header should be optional when full PASSporT is used. The iat
in PASSporT should provide enough protection for cut-and-paste attacks.
2. I think privacy considerations should be added that recommend using SIPS
since the data carried in PASSporT is likely considered personally
identifiable information and should not be transmitted in encrypted form.

Still, I wouldn't say I like quotes around the ppt param value since this
parameter differs from every other token parameter in SIP headers.
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 12:33 PM Alec Fenichel <[email-masked]>
wrote:

>    1. Require quotes around ppt param value
>    2. Make info param optional when using full form PASSporTs to make OOB
>    easier for transit providers
>    3. Allow info param to match claims other than x5u (e.g., jku, etc.)
>    to support DLT and other future PASSporT extensions that don’t use x5u
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> *From: *Roman Shpount <[email-masked]>
> *Date: *Tuesday, April 20, 2021 at 12:02
> *To: *Alec Fenichel <[email-masked]>
> *Cc: *Peterson, Jon <jon.peterson=[email-masked]>,
> Peterson, Jon <[email-masked]>, Marc Petit-Huguenin <
> [email-masked]>, IETF STIR Mail List <[email-masked]>, Russ
> Housley <[email-masked]>, Christer Holmberg <
> [email-masked]>
> My personal opinion is that we should try to organize an open SipIt
> interop event for both STIR and SHAKEN implementations. Based on the
> interop results, it might be good to do a new version of RFC 8224.
>
>
>

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 20 Apr 2021 17:44:09 +0000

Roman,

Is there text that I missed that makes the Date header required?

Let me rephrase my first proposed change:

The document should be prescriptive about whether quotes are required around the ppt parameter value or not

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Date: Tuesday, April 20, 2021 at 13:40

Alec,

1. The Date header should be optional when full PASSporT is used. The iat in PASSporT should provide enough protection for cut-and-paste attacks.

2. I think privacy considerations should be added that recommend using SIPS since the data carried in PASSporT is likely considered personally identifiable information and should not be transmitted in encrypted form.

Still, I wouldn't say I like quotes around the ppt param value since this parameter differs from every other token parameter in SIP headers.

_____________
Roman Shpount

On Tue, Apr 20, 2021 at 12:33 PM Alec Fenichel <[email-masked]> wrote:

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

Best Regards,

_____________
Roman Shpount

Jon,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Jon Peterson

Neustar, Inc.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Inline.

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 13:47:45 -0400

Hi Alec,

In https://tools.ietf.org/html/rfc8224#section-6.1 Step 3:

An authentication service MUST add a Date header field to SIP requests that
do not have one.

Best Regards,
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 1:44 PM Alec Fenichel <[email-masked]>
wrote:

>    1. The document should be prescriptive about whether quotes are
>    required around the ppt parameter value or not
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> *Date: *Tuesday, April 20, 2021 at 13:40
> 2. I think privacy considerations should be added that recommend using
> SIPS since the data carried in PASSporT is likely considered personally

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 20 Apr 2021 17:54:28 +0000

Proposed changes:

Be prescriptive about whether quotes are required around the ppt parameter value or not

Make the Date header optional

I’m not following the SIPS recommendation for privacy due to the PASSporT. The destination number, origination number, etc. are already in the SIP signaling. How does the PASSporT add sensitive data?

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Date: Tuesday, April 20, 2021 at 13:48

Hi Alec,

An authentication service MUST add a Date header field to SIP requests that do not have one.

Best Regards,

_____________
Roman Shpount

On Tue, Apr 20, 2021 at 1:44 PM Alec Fenichel <[email-masked]> wrote:

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

_____________
Roman Shpount

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

Best Regards,

_____________
Roman Shpount

Jon,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Jon Peterson

Neustar, Inc.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Inline.

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 14:02:46 -0400

On Tue, Apr 20, 2021 at 1:54 PM Alec Fenichel <[email-masked]>
wrote:

> Proposed changes:
>
>
>
>    1. Be prescriptive about whether quotes are required around the ppt
>    parameter value or not
>    4. Make the Date header optional
>
>
>
> I’m not following the SIPS recommendation for privacy due to the PASSporT.
> The destination number, origination number, etc. are already in the SIP
> signaling. How does the PASSporT add sensitive data?
>

Technically, even the origination and termination numbers are already PPI,
so they should not be carried unencrypted over the public internet.
Additional optional claims can be present in PASSporT, such as rich call
data (rcd), which makes the exposure even bigger. There is some language
regarding this in draft-ietf-stir-passport-rcd, but I think something
should be added to RFC 8224 as well.
_____________
Roman Shpount

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 20 Apr 2021 18:19:12 +0000

I do agree that we should transition away from x5u being the sole way to identify the keying material that signs PASSporTs. We ran into this already looking at x5c, for example, and I’ve heard of a couple others. That would be a patch for both RFC8224 and RFC8225, but it’s really more additive than corrective. From an IETF process perspective, I’d suggest doing that as an Internet-Draft that targets an update to RFC8224 and RFC8225 (rather than a bis of both).

Personally, I need to think more about the SIP Identity header “info” parameter being optional, but the original motivation for requiring it, as far as I can remember, was related to both compact form and to having VS’s sift through Identity headers by the trust anchors they trusted. For non-compact form PASSporTs used in closed networks with mandated trust anchors, those motivations at least are less of a concern. This is the first time I can recall that I’ve heard the suggestion that Date headers should not be added by AS’s, but on first glance I’m not sure I consider that a crucial thing to fix, anyway.

Jon Peterson
Neustar, Inc.

From: Alec Fenichel <[email-masked]>
Date: Tuesday, April 20, 2021 at 10:54 AM
To: Roman Shpount <[email-masked]>
Cc: "Peterson, Jon" <jon.peterson=[email-masked]>, "Peterson, Jon" <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Proposed changes:

1.       Be prescriptive about whether quotes are required around the ppt parameter value or not

2.       Make info param optional when using full form PASSporTs to make OOB easier for transit providers

3.       Allow info param to match claims other than x5u (e.g., jku, etc.) to support DLT and other future PASSporT extensions that don’t use x5u

Sincerely,

Alec Fenichel

In https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8224*section-6.1__;Iw!!N14HnBHF!tzqxtEpKWbcWzoqX-dhXQBq80PGw0mmVDUDpwaaQpYmaG-VLLmuJsui2zJU$ <https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8224*23section-6.1&data=04*7C01*7Calec.fenichel*40transnexus.com*7Cdbfa0be305214ff23a2b08d90424708f*7C8e2972a2d21d49acb00518e8ceaadee3*7C1*7C0*7C637545376833535180*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=*2FXjXtPkSDbBEwhecGcTO6EAJbikQr1cbR8PypfS1BdE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!N14HnBHF!tzqxtEpKWbcWzoqX-dhXQBq80PGw0mmVDUDpwaaQpYmaG-VLLmuJ_NrFKU8$ > Step 3:

Best Regards,
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 1:44 PM Alec Fenichel <[email-masked]<mailto:[email-masked]>> wrote:
Roman,

1.       The document should be prescriptive about whether quotes are required around the ppt parameter value or not

Sincerely,

Alec Fenichel

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 20, 2021 at 13:40
To: Alec Fenichel <[email-masked]<mailto:[email-masked]>>
Cc: Peterson, Jon <jon.peterson=[email-masked]<mailto:[email-masked]>>, Peterson, Jon <[email-masked]>, Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>, IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Proposal for update of erratum #6519
Alec,

On Tue, Apr 20, 2021 at 12:33 PM Alec Fenichel <[email-masked]<mailto:[email-masked]>> wrote:
Roman,

2.       Make info param optional when using full form PASSporTs to make OOB easier for transit providers

3.       Allow info param to match claims other than x5u (e.g., jku, etc.) to support DLT and other future PASSporT extensions that don’t use x5u

Sincerely,

Alec Fenichel

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 20, 2021 at 12:02
To: Alec Fenichel <[email-masked]<mailto:[email-masked]>>
Cc: Peterson, Jon <jon.peterson=[email-masked]<mailto:[email-masked]>>, Peterson, Jon <[email-masked]>, Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>, IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Proposal for update of erratum #6519
Alec,

Best Regards,
_____________
Roman Shpount

Sincerely,

Alec Fenichel

Jon Peterson
Neustar, Inc.

Sincerely,

Alec Fenichel

Inline.

Jon Peterson
Neustar, Inc.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 14:25:58 -0400

On Tue, Apr 20, 2021 at 2:19 PM Peterson, Jon <[email-masked]>
wrote:

> This is the first time I can recall that I’ve heard the suggestion that
> Date headers should not be added by AS’s, but on first glance I’m not sure
> I consider that a crucial thing to fix, anyway.
>
>
>

The Date header was an interop issue that I have encountered when dealing
with multiple carriers. This is due to their SBC vendor not inserting the
Date header and refusing to insert it since, according to them, it is
redundant and known to cause interop issues.
_____________
Roman Shpount

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 20 Apr 2021 18:29:32 +0000

Jon,

I don’t think it is an issue for an STI-VS to decode a PASSporT that comes from an untrusted source. Web servers decode JWTs received over the open internet all the time.

On second thought, perhaps we should get rid of the info parameter all together and instead use x5u, x5c, jku, etc. parameters. Otherwise, how does the STI-VS know which one to construct if a given PASSporT extension supports more than one?

We could even get rid of info, alg, and ppt parameters and just have generic params. RFC 8224 would basically say that when using compact form PASSporTs any claims not included in the signaling should be included as SIP parameters of the Identity header where the SIP parameter name matches the claim name, and the value matches the encoded claim value. Values would need to be quoted as they would be case/whitespace sensitive.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

From: Peterson, Jon <[email-masked]>
Date: Tuesday, April 20, 2021 at 14:19
To: Alec Fenichel <[email-masked]>, Roman Shpount <[email-masked]>
Cc: Peterson, Jon <jon.peterson=[email-masked]>, Marc Petit-Huguenin <[email-masked]>, IETF STIR Mail List <[email-masked]>, Russ Housley <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Jon Peterson

Neustar, Inc.

Proposed changes:

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Hi Alec,

Best Regards,

_____________
Roman Shpount

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

_____________
Roman Shpount

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

Best Regards,

_____________
Roman Shpount

Jon,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Jon Peterson

Neustar, Inc.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Inline.

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 20 Apr 2021 14:25:09 -0700

> version) should be used when constructing a JWT header.

Good point.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 20 Apr 2021 14:36:50 -0700

>      ident-type = "ppt" EQUAL ( ( token SWS ) / ( LDQUOT token RDQUOT ) )

I think that traditionally in SIP we do not accept SWS at the end of Header line.  But because EQUAL and SEMI both are already surrounded by SWS, we can revert back to DQUOTE without losing the ability of folding.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 18:28:45 -0400

I agree it should be

ident-type = "ppt" EQUAL ( ( token ) / ( DQUOTE token  DQUOTE ) )

For reference, quoted-string = SWS DQUOTE   *( qdtext / quoted‑pair )
DQUOTE, so no LWS is allowed after the value.
_____________
Roman Shpount

On Tue, Apr 20, 2021 at 5:36 PM Marc Petit-Huguenin <[email-masked]>
wrote:

> > Since RDQUOT allows whitespace after the double quote, do we need to
> allow whitespace after token when there are no quotes?
> >
> I think that traditionally in SIP we do not accept SWS at the end of
> Header line.  But because EQUAL and SEMI both are already surrounded by
> SWS, we can revert back to DQUOTE without losing the ability of folding.
>
> --
> Marc Petit-Huguenin

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 21:58:34 -0400

Jon,

I hope someone from the OpenSIPit can speak to that in more details, but
according to their status page (
https://opensipit.org/opensipit01-day-2-update/), they have encountered
several Date header issues as well:

    - lots of issues/quirks around the Date header field (now mandatory):
        * bad formatting (missing comma, GMT (good) vs. UTC (bad))
        * localization issues (Mi (bad) vs. Wed (good))
        * some teams forgot to build it at all
_____________
Roman Shpount

---

From: "Gorman, Pierce" <[email-masked]>
Date: Tue, 20 Apr 2021 16:44:21 +0000

+1 on Alec’s 3 proposed changes.

Best regards,

Pierce Gorman
Principal Engineer Sys Arch

Direct 913.439.4368 |  [email-masked] <mailto:[email-masked]> 

 <http://www.t-mobile.com/> t-mobile.com  | Follow T-Mobile on  <https://twitter.com/tmobile> Twitter,  <https://www.facebook.com/TMobile> Facebook and  <http://instagram.com/tmobile> Instagram  

From: Alec Fenichel <[email-masked]> 
Sent: Tuesday, April 20, 2021 11:33 AM
To: Roman Shpount <[email-masked]>
Cc: Peterson, Jon <jon.peterson=[email-masked]>; Peterson, Jon <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; IETF STIR Mail List <[email-masked]>; Russ Housley <[email-masked]>; Christer Holmberg <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Roman,

Sincerely,

Alec Fenichel

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

+1 (407) 760-0036

TransNexus

From: Roman Shpount <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, April 20, 2021 at 12:02
To: Alec Fenichel <[email-masked] <mailto:[email-masked]> >
Cc: Peterson, Jon <jon.peterson=[email-masked] <mailto:jon.peterson=[email-masked]> >, Peterson, Jon <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >, IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
Subject: Re: [stir] Proposal for update of erratum #6519

Alec,

Best Regards,

_____________
Roman Shpount

On Tue, Apr 20, 2021 at 11:31 AM Alec Fenichel <[email-masked] <mailto:[email-masked]> > wrote:

Jon,

Sincerely,

Alec Fenichel

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

+1 (407) 760-0036

TransNexus

From: Peterson, Jon <jon.peterson=[email-masked] <mailto:[email-masked]> >
Date: Tuesday, April 20, 2021 at 11:05
To: Alec Fenichel <[email-masked] <mailto:[email-masked]> >, Peterson, Jon <[email-masked] <mailto:[email-masked]> >, Roman Shpount <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >
Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
Subject: Re: [stir] Proposal for update of erratum #6519

Jon Peterson

Neustar, Inc.

From: stir <[email-masked] <mailto:[email-masked]> > on behalf of Alec Fenichel <alec.fenichel=[email-masked] <mailto:[email-masked]> >
Date: Tuesday, April 20, 2021 at 7:59 AM
To: "Peterson, Jon" <jon.peterson=[email-masked] <mailto:[email-masked]> >, Roman Shpount <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >
Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
Subject: Re: [stir] Proposal for update of erratum #6519

Sincerely,

Alec Fenichel

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

+1 (407) 760-0036

TransNexus

From: stir <[email-masked] <mailto:[email-masked]> > on behalf of Peterson, Jon <jon.peterson=[email-masked] <mailto:[email-masked]> >
Date: Tuesday, April 20, 2021 at 10:47
To: Roman Shpount <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >
Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
Subject: Re: [stir] Proposal for update of erratum #6519

Inline.

From: stir <[email-masked] <mailto:[email-masked]> > on behalf of Roman Shpount <[email-masked] <mailto:[email-masked]> >
Date: Monday, April 19, 2021 at 6:57 PM
To: Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >
Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
Subject: Re: [stir] Proposal for update of erratum #6519

On Mon, Apr 19, 2021 at 7:56 PM Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> > wrote:

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2021 17:53:07 +0000

Hi,

I have not been able to follow the discussion in detail, but is there a reason why we simply can's say:

ident-type = "ppt" EQUAL token / quoted-string

...and then add text saying that the only token characters are allowed?

Regards,

Christer

________________________________
From: Roman Shpount <[email-masked]>
Sent: Tuesday, April 20, 2021 5:20 PM
To: Russ Housley <[email-masked]>
Cc: Marc Petit-Huguenin <[email-masked]>; Christer Holmberg <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519

Hi Russ,

On Tue, Apr 20, 2021 at 9:22 AM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 19, 2021, at 9:57 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Russ

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 21 Apr 2021 11:12:46 -0700

> ...and then add text saying that the only token characters are allowed?

I believe that exceptions to ABNF should be kept to the minimal necessary.   Few implementers read the ABNF, few implementers read normative text.  That means that only the intersection of these two sets will do the right thing.

That's also why we should not deviate from the norm:  We should have used COMMA in Identity, ident-info-uri should have been a field right after signed-identity-digest (similar to name-addr).

Standards are not driven by the best protocol designers' work, but by the worse implementers' shortcomings.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Apr 2021 19:40:37 +0000

>I believe that exceptions to ABNF should be kept to the minimal necessary.

My suggestion is a subset of generic-param, which is the generic syntax for the parameters.

>Few implementers read the ABNF, few implementers read normative text.  That means that only the intersection of these two sets will do the right thing.
>
>That's also why we should not deviate from the norm:  We should have used COMMA in Identity, ident-info-uri should have been a field right after signed->identity-digest (similar to name-addr).

Perhaps, but that is not what the issue is about.

Regards,

Christer

--
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=f5436fb7-aad856b2-f5432f2c-86959e472243-d9535674738af26e&q=1&e=7a194cb8-6230-48c3-b23f-d2e231acea1c&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Roman Shpount <[email-masked]>
Date: Wed, 21 Apr 2021 16:27:09 -0400

> My suggestion is a subset of generic-param, which is the generic syntax

There is no reason not to keep ABNF as specific as possible.

Saying that
ident-type =  "ppt" EQUAL ( token / ( DQUOTE token DQUOTE ) )
leaves no room for misinterpretation.

There are quite a few people who use ABNF grammars to create field parsers
or validators. Providing them with the most specific grammar possible makes
their job easier.

As far as other changes are concerned, I would suggest getting an open
interop event organized. Based on the results, it is possible to see all
the issues or pain points with the current specification and decide if a
specification update is necessary. If the group sees a clear need for a
document update, we can update some of the design limitations of the
current specification.

Best Regards,
_____________
Roman Shpount

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 21 Apr 2021 14:34:16 -0700

No.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Apr 2021 14:37:35 +0000

No what?

________________________________
From: Marc Petit-Huguenin <[email-masked]>
Sent: Thursday, April 22, 2021 12:34 AM
To: Christer Holmberg <[email-masked]>; Roman Shpount <[email-masked]>; Russ Housley <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519 - ppt syntax

No.

--
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=3c808f74-631bb671-3c80cfef-86d2114eab2f-c675e5fca897c209&q=1&e=ff81ea56-63b5-4201-94e2-6d0158073ba1&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Apr 2021 14:41:51 +0000

Hi,

>There are quite a few people who use ABNF grammars to create field parsers or validators. Providing them with the most specific grammar possible makes their job easier.

In general I agree. But, people should not have to modify their existing parsers if they can already handle both quoted and non-quoted ppt values.

Regards,

Christer

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Apr 2021 09:11:34 -0700

This was shorthand for 1) I disagree to everything you said, but I have nothing to add to what I already said and 2) I want to signal to whoever is deciding consensus that I disagree.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Apr 2021 16:41:30 +0000

Ok

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Marc Petit-Huguenin <[email-masked]>
Sent: Thursday, April 22, 2021 7:11:34 PM
To: Christer Holmberg <[email-masked]>; Roman Shpount <[email-masked]>; Russ Housley <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519 - ppt syntax

--
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=94d2e976-cb49d194-94d2a9ed-86073b36ea28-1c860d9bb52fa7a0&q=1&e=8f0f87d9-0c36-4141-920a-25094faef6dc&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Apr 2021 13:11:06 -0400

On Thu, Apr 22, 2021 at 10:41 AM Christer Holmberg <
[email-masked]> wrote:

> >There are quite a few people who use ABNF grammars to create field
> parsers or validators. Providing them with the most specific grammar
> possible makes their job easier.
>
> In general I agree. But, people should not have to modify their existing
> parsers if they can already handle both quoted and non-quoted ppt values.
>
>
In general, they would not need to update the parser. The critical point
here is the opposite. We do not want to require that anyone who only
supports quoted tokens as the ppt value would have to update their parser
to support the quoted strings. If they choose to support full quoted
strings and then accept a wider range of values (like accept spaces around
the token), they can do so without causing any interop issues. As long as
they do not send anything that does not match the grammar, this is
acceptable.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Apr 2021 17:43:47 +0000

Hi,

>In general, they would not need to update the parser. The critical point here is the opposite. We do not want to require that anyone who only supports quoted tokens as the ppt value would have to >update their parser to support the quoted strings. If they choose to support full quoted strings and then accept a wider range of values (like accept spaces around the token), they can do so without >causing any interop issues. As long as they do not send anything that does not match the grammar, this is acceptable.

That's why I said that we should only allow token inside the quoted string, not having to deal with spaces etc.

How does the suggested "DQUOTE token DQUOTE" syntax prevent spaces between the quotes and the token characters?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Apr 2021 13:49:11 -0400

> the quotes and the token characters?
DQUOTE = %x22
token = 1*( alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'"
/ "~" )

Based on this,  "DQUOTE token DQUOTE" cannot contain spaces.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Apr 2021 17:54:05 +0000

Hi,

Doesn't the SIP ABNF allow spaces (LWS) between the different "syntax parts", DQUOTE and token in this case?

Regards,

Christer

________________________________
From: Roman Shpount <[email-masked]>
Sent: Thursday, April 22, 2021 8:49 PM
To: Christer Holmberg <[email-masked]>
Cc: Marc Petit-Huguenin <[email-masked]>; Russ Housley <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519 - ppt syntax

On Thu, Apr 22, 2021 at 1:43 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
How does the suggested "DQUOTE token DQUOTE" syntax prevent spaces between the quotes and the token characters?

DQUOTE = %x22
token = 1*( alphanum /  "-" /  "." /  "!" /  "%" /  "*" /  "_" /  "+" /  "`" /  "'" /  "~" )

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Apr 2021 14:00:37 -0400

> parts", DQUOTE and token in this case?

I do not think so. At least all other elements like LQUOT and
DQUOT explicitly define where LWS is allowed.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Apr 2021 18:02:52 +0000

Hi,

Another thing. Since we are now using DQUOTE, won't those become part of the ppt value? I guess we don't want that.

Regards,

Christer

Sent: Thursday, April 22, 2021 9:00 PM

On Thu, Apr 22, 2021 at 1:54 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Doesn't the SIP ABNF allow spaces (LWS) between the different "syntax parts", DQUOTE and token in this case?

I do not think so. At least all other elements like LQUOT and DQUOT explicitly define where LWS is allowed.
_____________
Roman Shpount

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Apr 2021 11:03:43 -0700

> Doesn't the SIP ABNF allow spaces (LWS) between the different "syntax parts", DQUOTE and token in this case?

RFC 5234:

"Any grammar that wishes to permit linear white space around
  delimiters or string segments must specify it explicitly."

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Apr 2021 11:07:20 -0700

> Another thing. Since we are now using DQUOTE, won't those become part of the ppt value? I guess we don't want that.

The text I proposed is taking care of that:

...a quoted value whose unquoted part is equivalent to the token in the "ppt" parameter, normalized to contain only lowercase characters...

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Apr 2021 16:27:11 +0000

Hi,

With quoted string we wouldn't need such text.

Regards,

Christer

-----Original Message-----
From: Marc Petit-Huguenin <[email-masked]> 
Sent: torstai 22. huhtikuuta 2021 21.07
To: Christer Holmberg <[email-masked]>; Roman Shpount <[email-masked]>
Cc: Russ Housley <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519 - ppt syntax

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=4e558df3-11ceb4f3-4e55cd68-86fc6812c361-acafa30285f7a74e&q=1&e=5e14ccd9-899a-48ea-bc44-1202f6c375d5&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 23 Apr 2021 09:34:27 -0700

> With quoted string we wouldn't need such text.

You would need an even longer text that explains that a quoted-string that contains characters that are not in the definition of token -- excepted for the initial quote and the last quote -- is invalid.  You would also need to explain that, contrary to the rule for a quoted-string, the string is case-insensitive.  And you still have to explain that the string needs to be normalized before copy in the JSON document.

So many words.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 23 Apr 2021 09:41:50 -0700

I have to ask:  What, in your implementation of STIR, made you so confident that what you propose is better than what Roman (I assume also a SIP implementer) and I (a 5 times SIP implementer and one time STIR implementer) propose?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Apr 2021 16:49:51 +0000

I didn't know the rules in IETF were "we believe in rough consensus - or in whoever has the most SIP implementations".

(FWIW, I do have some SIP implementation experience myself.)

However, I have not objected to your proposal. My issue is whether we really need to define a new syntax for a string value, that doesn't exist anywhere else.

Regards,

Christer

-----Original Message-----
From: Marc Petit-Huguenin <[email-masked]> 
Sent: perjantai 23. huhtikuuta 2021 19.42
To: Christer Holmberg <[email-masked]>; Roman Shpount <[email-masked]>
Cc: Russ Housley <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Proposal for update of erratum #6519 - ppt syntax

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=5fb11394-002a2af5-5fb1530f-86d8a30ca42b-b2a5f71da88e95f2&q=1&e=e9ee079a-7a86-4ece-b168-5187a95afadd&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 23 Apr 2021 09:57:49 -0700

And running code...

That was a genuine question -- the language we use drive the way we think.  Handcoding a parser as a state machine vs using a LL(1) parser vs an LR parser introduce different difficulties when writing them, and I was wondering if your insistence was because of that.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Apr 2021 17:03:53 +0000

>And running code...
>
>That was a genuine question -- the language we use drive the way we think.  Handcoding a parser as a state machine vs using a LL(1) parser vs an LR parser introduce different difficulties when
>writing them, and I was wondering if your insistence was because of that.

I have many years of parser implementation experience. Having said that, this specific issue is not related to something I am currently implementing, but more in general.

But, if I am the only one having that issue, I am fine to drop it in order to make progress. I guess you'd agree that SIP is not the first choice if looking for clean and proper syntax :)

Regards,

Christer

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=2e44e216-71dfdb55-2e44a28d-861fcb972bfc-5f2c34c4704afcbf&q=1&e=c10aea91-1104-429c-a6ce-27af6838c68c&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 23 Apr 2021 10:05:45 -0700

> But, if I am the only one having that issue, I am fine to drop it in order to make progress. I guess you'd agree that SIP is not the first choice if looking for clean and proper syntax :)

Emphatically yes.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Apr 2021 14:11:22 -0400

On Fri, Apr 23, 2021 at 1:03 PM Christer Holmberg <
[email-masked]> wrote:

> >That was a genuine question -- the language we use drive the way we
> think.  Handcoding a parser as a state machine vs using a LL(1) parser vs
> an LR parser introduce different difficulties when
> I have many years of parser implementation experience. Having said that,
> this specific issue is not related to something I am currently
> implementing, but more in general.
>
> But, if I am the only one having that issue, I am fine to drop it in order
> to make progress. I guess you'd agree that SIP is not the first choice if
> looking for clean and proper syntax :)
>
>
I am currently maintaining 3 different SIP stacks (2 with handwritten
parsers and one with a rule-based parser). I also got a STIR
implementation, even though it is not as mature as I would like.

I typically test my parsers using input fuzzer to see where they produce
different results between each other or other open-source parsers. My main
problem is that if we define ident-type as "ppt" EQUAL token /
quoted-string, then something like ppt="\s\h\a\k\e\n" is potentially legal.
I do not want to update parsers that do not support such syntax. We can put
some language that prohibits this, but having an ABNF rule and text saying
that the value is token surrounded by quotes archives the same goal much
cleaner.

Best Regards,
_____________
Roman Shpount

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 27 Apr 2021 04:31:06 -0700

On 4/26/21 9:11 AM, Gorman, Pierce wrote:
> Jon,
> 
>   
> 
> I thought your suggestion of an Internet-Draft was very interesting.  I don’t think I’ve ever heard of an Internet-Draft updating two RFCs at the same time but that sounds like a good idea.  

RFC 8996 updated 84 RFCs, probably breaking a record.

> Are you thinking that would result in a new RFC?  The  <https://www.ietf.org/standards/ids/guidelines/> guidelines on authoring an I-D indicate that is a possible outcome.
> 
>   
> 
> If there is a willingness to do and accept those updates, and also a SIPiT event to help illuminate best choices, this could be a very good time to create the I-D.
> 
>   
> 
> Pierce
> 
>   
> 
> Sent: Tuesday, April 20, 2021 1:30 PM
> To: Peterson, Jon <[email-masked]>; Roman Shpount <[email-masked]>
> Cc: Peterson, Jon <jon.peterson=[email-masked]>; Marc Petit-Huguenin <[email-masked]>; IETF STIR Mail List <[email-masked]>; Russ Housley <[email-masked]>; Christer Holmberg <[email-masked]>
> From: Peterson, Jon <[email-masked] <mailto:[email-masked]> >
> To: Alec Fenichel <[email-masked] <mailto:[email-masked]> >, Roman Shpount <[email-masked] <mailto:[email-masked]> >
> Cc: Peterson, Jon <jon.peterson=[email-masked] <mailto:jon.peterson=[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >, IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
> From: Alec Fenichel <[email-masked] <mailto:[email-masked]> >
> To: Roman Shpount <[email-masked] <mailto:[email-masked]> >
> Cc: "Peterson, Jon" <jon.peterson=[email-masked] <mailto:jon.peterson=[email-masked]> >, "Peterson, Jon" <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >, IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
> On Tue, Apr 20, 2021 at 1:44 PM Alec Fenichel <[email-masked] <mailto:[email-masked]> > wrote:
> 
> Roman,
> 
>   
> 
> Cc: Peterson, Jon <jon.peterson=[email-masked] <mailto:[email-masked]> >, Peterson, Jon <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >, IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
> On Tue, Apr 20, 2021 at 12:33 PM Alec Fenichel <[email-masked] <mailto:[email-masked]> > wrote:
> 
> Roman,
> 
>   
> 
> Cc: Peterson, Jon <jon.peterson=[email-masked] <mailto:[email-masked]> >, Peterson, Jon <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >, IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]> >, Russ Housley <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked]>

---

From: "Gorman, Pierce" <[email-masked]>
Date: Mon, 26 Apr 2021 16:11:33 +0000

Jon,

I thought your suggestion of an Internet-Draft was very interesting.  I don’t think I’ve ever heard of an Internet-Draft updating two RFCs at the same time but that sounds like a good idea.  Are you thinking that would result in a new RFC?  The  <https://www.ietf.org/standards/ids/guidelines/> guidelines on authoring an I-D indicate that is a possible outcome.

Pierce

Jon,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Jon Peterson

Neustar, Inc.

Proposed changes:

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Hi Alec,

Best Regards,

_____________
Roman Shpount

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

_____________
Roman Shpount

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

Best Regards,

_____________
Roman Shpount

Jon,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Jon Peterson

Neustar, Inc.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Inline.

A literalist.  Fantastic.

Jon Peterson

Neustar, Inc.