Re: [stir] [Technical Errata Reported] RFC8224 (6519)

[Roman Shpount <[e-mail]>]

All the registered Personal Assertion Tokens are tokens:
https://www.iana.org/assignments/passport/passport.xhtml.

There is nothing in RFC8225 that limits the ppt header parameter's value,
so to be compatible, ident-type = "ppt" EQUAL (token / quoted-string) is
correct. This, however, does not reflect the decision to always put quotes
around the ppt value from IETF 101.

If this were up to me, I would say that the original ABNF is correct and
all the other documents and implementation which put quotes around the ppt
value are wrong. After all, these quotes serve no purpose except using
extra two bytes. Furthermore, there is no reason the use anything except
tokens to identify PASSporT Extensions.

I would also like to point out that the definition of info parameter is
also problematic since it is not a valid generic-param:
ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT

A quoted-string should have been used for the info, not the LAQUOT
absoluteURI RAQUOT.

I assume it is too late to fix either of these things.
_____________
Roman Shpount


On Wed, Apr 7, 2021 at 3:25 PM Marc Petit-Huguenin <[e-mail]>
wrote:

> Hi Roman,
>
> On 4/7/21 9:18 AM, Roman Shpount wrote:
> > Hi Christer,
> >
> > This is exactly the issue. ATIS documents and other RFCs like rfc8946 use
> > ppt with a quoted token.
>
> Shouldn't the ABNF now be, to be compatible with non-SHAKEN
> implementations, this:
>
> ident-type = "ppt" EQUAL (token / quoted-string)
>
> >
> > Also, according to IETF 101 STIR notes (which you took), the ppt
> > token value should always be quoted. I am not sure why it needed to be
> > quoted (I think this is wrong), but that was the decision.
> > _____________
> > Roman Shpount
> >
> >
> > On Wed, Apr 7, 2021 at 11:23 AM Christer Holmberg <
> > [e-mail]> wrote:
> >
> >> Hi,
> >>
> >> I have not been involved in the discussions, so my apologies for asking
> >> something that have been discussed already, but what is the reason for
> the
> >> change? If you anyway are only going to allow "token" characters, why
> the
> >> quotes? Is the only reason to align with how the parameter is used in
> other
> >> specs?
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >> -----Original Message-----
> >> From: stir <[e-mail]> On Behalf Of RFC Errata System
> >> Sent: tiistai 6. huhtikuuta 2021 8.21
> >> To: [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]; [e-mail]; Francesca Palombini <
> >> [e-mail]>; [e-mail];
> >> [e-mail]
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> Subject: [stir] [Technical Errata Reported] RFC8224 (6519)
> >>
> >> The following errata report has been submitted for RFC8224,
> "Authenticated
> >> Identity Management in the Session Initiation Protocol (SIP)".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >>
> >>
> https://protect2.fireeye.com/v1/url?k=ac0542ba-f39e7bbf-ac050221-86959e472243-713aff0f88c18be4&q=1&e=6be2f688-f156-4c8b-953f-2bec6cf24d76&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6519
> >>
> >> --------------------------------------
> >> Type: Technical
> >> Reported by: Roman Shpount <[e-mail]>
> >>
> >> Section: 4
> >>
> >> Original Text
> >> -------------
> >> ident-type = "ppt" EQUAL token
> >>
> >> Corrected Text
> >> --------------
> >> ident-type = "ppt" EQUAL DQUOTE token DQUOTE
> >>
> >> Notes
> >> -----
> >> Based on IETF 101 STIR notes ptr= values should always be quoted. Also,
> >> ATIS-1000074 is using double quotes around ppt value.
> >>
> >> Instructions:
> >> -------------
> >> This erratum is currently posted as "Reported". If necessary, please use
> >> "Reply All" to discuss whether it should be verified or rejected. When a
> >> decision is reached, the verifying party can log in to change the status
> >> and edit the report, if necessary.
> >>
> >> --------------------------------------
> >> RFC8224 (draft-ietf-stir-rfc4474bis-16)
> >> --------------------------------------
> >> Title               : Authenticated Identity Management in the Session
> >> Initiation Protocol (SIP)
> >> Publication Date    : February 2018
> >> Author(s)           : J. Peterson, C. Jennings, E. Rescorla, C. Wendt
> >> Category            : PROPOSED STANDARD
> >> Source              : Secure Telephone Identity Revisited
> >> Area                : Applications and Real-Time
> >> Stream              : IETF
> >> Verifying Party     : IESG
> >>
> >> _______________________________________________
> >> stir mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/stir
> >>
> >
> >
> > _______________________________________________
> > stir mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/stir
> >
>
>
> --
> Marc Petit-Huguenin
> Email: [e-mail]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>