Subject: [stir] Second WG Last Call for RFC4474bis

From: Russ Housley <[email-masked]>
Date: Sat, 10 Sep 2016 12:01:21 -0400

A revised document to address the issues raised in the first WG Last Call
on this document was posted yesterday.
(https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-12.txt).

This message starts a second two-week WG Last Call for this document,
which will end on 24 September 2016.

Please review the document and send comments on it to the STIR WG mail
list.  Please clearly state your opinion as to whether the document is
ready for publication as a standards-track RFC.  Remember that support
for publication is needed, so if you think the document is ready to go
forward, please say so.

Thanks,
Russ & Robert

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Sep 2016 10:21:43 -0400

I was talking to a developer a few minutes ago, and he found a small bug.  It is very simple to fix.  Maybe he will find other bugs as development continues …

In section 4, the ABNF includes:

      base64-char = ALPHA / DIGIT / "/" / "+"

This line should say:

      base64-char = ALPHA / DIGIT / "/" / “+” / “="

Russ

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Sep 2016 13:29:10 -0400

>       base64-char = ALPHA / DIGIT / "/" / “+” / “="

That is an improvement.  However, the document lacks any definition of 
how base64 encoding/decoding works. I suggest a reference to RFC4648. 
That RFC has two distinct base64 encodings: "base64" and "base64url". 
The examples in this draft clearly use "base64" because some of them 
contain "/".

Also, it would be possible to write the syntax to more tightly define 
the syntax for base64:

       canonical-str = "canon" EQUAL LDQUOT base64-encoding RDQUOT
       base64-encoding =
          *(3base64-char) [ (2base64-char "=") / (base64-char 2"=") ]

OTOH referencing RF4648 may be sufficient.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Sep 2016 14:26:10 -0400

Replying to myself :-(

I discovered more problems with this:

I presume that there should be some consistency between this document 
and passport and JWS regarding how base64 encoding is done.

* JWS [RFC7515] defines a modified encoding that is like "base64url" 
from RFC4648 except that it omits the trailing "=" for padding. It uses 
BASE64URL(octets) to denote this.

* passport references JWS, and also uses BASE64URL in examples.

* as I noted below, the examples in rfc4474bis clearly use "base64" 
encoding as defined in RFC4648, including the trailing "=" pad characters.

ISTM the proper fix for this is for both rfc4474bis and passport to 
explicitly reference RFC7515 for the definition of BASE64URL. Then the 
examples in 4474bis need to be changed accordingly. Once this is done 
there is no need for allowing "=" in the syntax.

More below.

On 9/13/16 1:29 PM, Paul Kyzivat wrote:
>> I was talking to a developer a few minutes ago, and he found a small
>> bug.  It is very simple to fix.  Maybe he will find other bugs as
>> development continues …
>>

Actually, now it should be:

          base64-char = ALPHA / DIGIT / "-" / “_”

>          *(3base64-char) [ (2base64-char "=") / (base64-char 2"=") ]

The above isn't right. I was going to correct it, but now there is no 
need to do so.

	Thanks,
	Paul

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Sep 2016 14:58:35 -0400

On Sep 13, 2016, at 2:26 PM, Paul Kyzivat <[email-masked]> wrote:

> I presume that there should be some consistency between this document and passport and JWS regarding how base64 encoding is done.
> 
> * JWS [RFC7515] defines a modified encoding that is like "base64url" from RFC4648 except that it omits the trailing "=" for padding. It uses BASE64URL(octets) to denote this.
> 
> * as I noted below, the examples in rfc4474bis clearly use "base64" encoding as defined in RFC4648, including the trailing "=" pad characters.
> 
> ISTM the proper fix for this is for both rfc4474bis and passport to explicitly reference RFC7515 for the definition of BASE64URL. Then the examples in 4474bis need to be changed accordingly. Once this is done there is no need for allowing "=" in the syntax.
> 
> More below.
> 
> The above isn't right. I was going to correct it, but now there is no need to do so.
> 

You are right, the equal sign is not needed.  JWT uses Base64url encoding, which is defined in RFC 7515.  Base64url encoding produces the URL-safe and filename-safe result.  It uses “-“ instead of “+“, it uses “_” instead of “/“, and it strips any trailing “=“ characters.

RFC 7515, Appendix C shows how to convert a Base64 string to a Base64url string.

So, the ABNF above should be:

      signed-identity-digest = LDQUOT *base64url-char RDQUOT

      canonical-str = "canon" EQUAL LDQUOT *base64url-char RDQUOT

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

Russ

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Sep 2016 22:27:22 +0000

We'll cite RFC7515 Appendix C for the base64 in the next rev. We'll also
remove the gratuitous uses of "\".

Additionally, we've gotten a request from the implementers at SIPit to
remove the leading and trailing quotes (LDQUOT and RDQUOT) around the
signed-identity-digest and the canon parameter value in the Identity
header. The presence of the quotes is really just mechanism grandfathered
in from RFC4474; it adds a few bites but don't seem to add any value.
Unless anyone objects, we'll remove those quotes from the syntax in the
next version. 

Jon Peterson
Neustar, Inc.

On 9/13/16, 11:58 AM, "stir on behalf of Russ Housley"
<[email-masked] on behalf of [email-masked]> wrote:

>>>> development continues Š
>>>>      base64-char = ALPHA / DIGIT / "/" / ³+² / ³="
>> 
>>         base64-char = ALPHA / DIGIT / "-" / ³_²
>> 
>You are right, the equal sign is not needed.  JWT uses Base64url
>encoding, which is defined in RFC 7515.  Base64url encoding produces the
>URL-safe and filename-safe result.  It uses ³-³ instead of ³+³, it uses
>³_² instead of ³/³, and it strips any trailing ³=³ characters.
>
>     base64url-char = ALPHA / DIGIT / ³_" / ³-³
>
>Russ
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Sep 2016 11:11:55 -0400

I was talking to several implementers during SIPit32.  There was some surprise that JOSE and PKIX have specified different syntax for an ECDSA signature value.  I suggest that we include a warning about this in at least one of the documents.  I am not totally sure that 4474bis is the best place, and I’m pleased to let the authors select the best location or locations.  I propose some text below.

Russ

= = = = = = = =

Implementation Considerations

   An ECDSA signature is comprised of two values, called r and s.  These
   signatures are represented in two different ways in PASSporT and
   certificates.  PASSport signature values follow the conventions
   specified in JSON Web Algorithms (JWA) [RFC7518], where r and s are
   concatenated without any stripping or padding.  Since r and s are
   always the same length, dividing the signature value in half will
   recover the r and s values.  Certificate signature values follow the
   conventions in [RFC3279], where the r and s are ASN.1-encoded as a
   SEQUENCE of two non-negative integer values.  If the high order bit
   is set, then a zero octet is prepended to produce a positive integer
   value.  Recovery of the r and s values requires the removal of the
   added zero octet.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Sep 2016 21:41:23 -0400

I did my AD review of this document early to try to expedite the process.

= General =

Should this document obsolete RFC 4474? Apologies if this was discussed and I'm failing to recall it. My answer would be yes I think, since new implementations of RFC 4474 are discouraged and this document is deprecating its syntax and its registries.

= Section 4.1 =

(1)
"Third, the JSON key "iat" MUST appear, set to the value of a
      quoted encoding of the value of the SIP Date header field as a
      JSON NumericDate (as UNIX time, per [RFC7519] Section 2)."

I think this needs one more sentence to explain that while RFC 7519 specifies that "iat" reflect the time the JWT was issued, there may be cases where an authorization service mints a JWT on behalf of an endpoint at some point later than what the SIP Date reflects. Given that the JWT is being created on behalf of the user (and how and why "iat" is used by 4474bis implementations), using the SIP Date rather than the time at which the JWT is actually created is acceptable.

(2)
"Defining how a SIP implementation
   would provision multiple originating or destination identities is
   left as a subject for future specification."

I'm assuming this meant to say that defining how a STIR implementation deals with multiple identities is what is left for future specification. Is that correct? If so, it would be helpful to clarify.

(3)
"Also note that in some cases, the
   "orig" and "dest" arrays might be populated with more than one value."

The passport spec says that "orig" MUST only have one value. Should this text align with that? Or is this meant to allow for future extensibility of passport?

= Section 8.3 =

(1)
"This will be the case, for
      example, for nationally-specific service numbers (e.g. 911, 112);
      however, the routing procedures associated with those numbers will
      likely make sure that the verification service understands the
      context of their use."

I don't understand what is meant by the text after the semi-colon. Is the point that the lack of canonicalization is ok because a verifier that is asked to verify 112 will be designed to know that 112 is special?

(2)
"If not, implementations SHOULD convert the number into E.164 format,
      adding a country code if necessary; this may involve transforming
      the number from a dial string (see [RFC3966]), removing any
      national or international dialing prefixes or performing similar
      procedures.  ... 
      Other transformations during canonicalization MAY be made in
      accordance with specific policies used within a local domain."

Aren't all of the "other transformations" subsumed under the umbrella of converting to E.164 format? I find it confusing to see these discussed as two separate requirements. I think it's fine to point out that some domains will need to take their own unique steps to eventually get their numbers into E.164 format, but that doesn't imply that there is one set of transformations that SHOULD happen and another set of transformations that MAY happen, right?  

= Section 13.3 =

Shouldn't the existing alg parameter have its reference updated to point to this document?

Nits:

= Section 1 =

A forward reference to Section 10 should be added to the last paragraph.

= Section 2 =

s/from an "identity field" a SIP request/from an "identity field" in a SIP request/

= Section 4.1 =

"the following elements message MUST be placed" -- I'm assuming "message" is extraneous and should be deleted? 

s/key "typ" key/key "typ"/

s/from addr-spec of the From header/from the addr-spec component of the From header/

OLD
This specification inherits
   from the PASSporT specification one value for the 'alg' parameter:
   'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
   digital signature.  All implementations of this specification MUST
   support the required signing algorithms of PASSporT.

NEW
All implementations of this specification MUST support the required signing algorithms of PASSporT. At present there is one mandatory-to-support value for the 'alg' parameter:
   'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
   digital signature.  
   
= Section 6.2.1 =

I think it would help to provide a little bit of rationale for this recommendation: "As a guideline, this specification recommends that only if a
   verifier determines all Identity header fields within a message are
   invalid should the request be considered to have an invalid identity."

= Section 6.2.2 =

s/reason phase/reason phrase/

= Section 10 =

OLD
it would likely fail the request due to the absence of an
   Identity-Info header field with a 436 response code.

NEW
it would likely fail the request with a 436 response code due to the absence of an
   Identity-Info header field.

= Section 13.4 =

I think this section should clearly instruct IANA to delete the registry.

Alissa

> On Sep 10, 2016, at 12:01 PM, Russ Housley <[email-masked]> wrote:
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 22 Sep 2016 19:12:49 +0000

Thanks, we can get these cleaned up. A few notes below.

Jon Peterson
Neustar, Inc.

On 9/20/16, 6:41 PM, "stir on behalf of Alissa Cooper"
<[email-masked] on behalf of [email-masked]> wrote:

>I think this needs one more sentence to explain that while RFC 7519
>specifies that "iat" reflect the time the JWT was issued, there may be
>cases where an authorization service mints a JWT on behalf of an endpoint
>at some point later than what the SIP Date reflects. Given that the JWT
>is being created on behalf of the user (and how and why "iat" is used by
>4474bis implementations), using the SIP Date rather than the time at
>which the JWT is actually created is acceptable.

Okay, we can explain a bit - I think probably what the text needs to say
is that the auth service should when adding "iat" inspect the Date and
make sure it is within the freshness window before signing. Also, if for
whatever reason the auth service wants to sign what it sees as the Date,
rather than what the SIP header says is the Date, it is allowed to do so
provided that it includes "canon". The text that supports this behavior is
given in the verification service behavior (and in 12.1) but not really
here.

>I'm assuming this meant to say that defining how a STIR implementation
>deals with multiple identities is what is left for future specification.
>Is that correct? If so, it would be helpful to clarify.

Well, this means more aligning STIR with potential ways that SIP might
signify that a request is "To" multiple destinations or "From" multiple
parties, say. Even when PAI is present and is different from the From,
there is still a general sense in personal communications that they are
from some person (a persona even). We do have some vague notion that we
want to work with meshed and centralized conferences, though, and don't
want to close the door on that, which is why there's some forward-looking
text about this here, and why the text is pretty broad.

>The passport spec says that "orig" MUST only have one value. Should this
>text align with that? Or is this meant to allow for future extensibility
>of passport?

This shows that we're not being entirely consistent in our
future-proofing. I'd be willing to narrow this down to only one "orig"
identity being allowed (and thus bring rfc4474bis into parity with
PASSporT on this). Like I said, generally speaking personal communication
are from like one person.

>I don't understand what is meant by the text after the semi-colon. Is the
>point that the lack of canonicalization is ok because a verifier that is
>asked to verify 112 will be designed to know that 112 is special?

It means that routing procedures for service numbers are very unusual, and
that the meaning of a service number is much more specific to its context
than is an E.164 number. The process of successfully routing to 911
necessarily involves the hops (and any STIR intermediaries) being in a
context where 911 will be understood. I can try to find a more helpful
wording for that.

>Aren't all of the "other transformations" subsumed under the umbrella of
>converting to E.164 format? I find it confusing to see these discussed as
>two separate requirements. I think it's fine to point out that some
>domains will need to take their own unique steps to eventually get their
>numbers into E.164 format, but that doesn't imply that there is one set
>of transformations that SHOULD happen and another set of transformations
>that MAY happen, right?

No, I think you're right. It is all effectively one set of transformations
that we are RECOMMENDing: we can anticipate what some members of the set
are, but not others. I'll reword accordingly.

>Shouldn't the existing alg parameter have its reference updated to point

Sure, good point.

Will fix the nits. Just one to comment on:

>
>= Section 6.2.1 =
>
>I think it would help to provide a little bit of rationale for this
>recommendation: "As a guideline, this specification recommends that only
>if a

The idea here is that if you don't support a "ppt" or lack some private
credential required to access one Identity header, that doesn't mean you
still can't find another Identity header that you can understand and
validate in the request, and that if you find at least one that looks
valid, you can accept the identity it covers. Maybe it would help to
rephrase this affirmatively that way, rather than describing the rainy day
case.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 22 Sep 2016 14:16:52 -0500

On Tue, Sep 20, 2016 at 8:41 PM, Alissa Cooper <[email-masked]> wrote:

> Should this document obsolete RFC 4474? Apologies if this was discussed
> and I'm failing to recall it. My answer would be yes I think, since new
> implementations of RFC 4474 are discouraged and this document is
> deprecating its syntax and its registries.
>
[MB] I made this comment a couple versions back and it hadn't yet been
incorporated.  I personally think it should be obsoletes as opposed to
updates.  [/MB]

> at some point later than what the SIP Date reflects. Given that the JWT is
> being created on behalf of the user (and how and why "iat" is used by
> 4474bis implementations), using the SIP Date rather than the time at which
> the JWT is actually created is acceptable.
>
> (2)
> deals with multiple identities is what is left for future specification. Is
> that correct? If so, it would be helpful to clarify.
>
> (3)
> text align with that? Or is this meant to allow for future extensibility of
> passport?
>
> = Section 8.3 =
>
> (1)
> two separate requirements. I think it's fine to point out that some domains
> will need to take their own unique steps to eventually get their numbers
> into E.164 format, but that doesn't imply that there is one set of
> transformations that SHOULD happen and another set of transformations that
> MAY happen, right?
>
> = Section 13.3 =
>
> All implementations of this specification MUST support the required
> signing algorithms of PASSporT. At present there is one
> mandatory-to-support value for the 'alg' parameter:
> recommendation: "As a guideline, this specification recommends that only if
> a

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 22 Sep 2016 19:35:37 +0000

= General =

Should this document obsolete RFC 4474? Apologies if this was discussed and I'm failing to recall it. My answer would be yes I think, since new implementations of RFC 4474 are discouraged and this document is deprecating its syntax and its registries.
[MB] I made this comment a couple versions back and it hadn't yet been incorporated.  I personally think it should be obsoletes as opposed to updates.  [/MB]

Sorry, that is the plan, yes.

Jon Peterson
Neustar, Inc

---

From: Russ Housley <[email-masked]>
Date: Sun, 25 Sep 2016 12:06:24 -0400

The Second WG Last Call has completed for:
   - draft-ietf-stir-rfc4474bis-12, 
   - draft-ietf-stir-certificates-08, and
   - draft-ietf-stir-passport-07.

A significant change was proposed. Many people spoke is support of that change, and no one spoke against it.  This change impacts both draft-ietf-stir-rfc4474bis an draft-ietf-stir-passport.

In addition, many clarifications were suggested that impact all three documents.

Authors, can updates to all three document get posted in the next few days?

Russ

---

From: Chris Wendt <[email-masked]>
Date: Mon, 26 Sep 2016 09:21:48 -0400

Yes i can do that as well as incorporate changes for AD review comments

> On Sep 25, 2016, at 12:06 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 26 Sep 2016 11:43:36 -0400

> On Sep 22, 2016, at 3:12 PM, Peterson, Jon <[email-masked]> wrote:
> 
>> 
>> (2)

Ok. I was reading this to mean the From+PAI case in current deployment, which is why it sounded confusing to me.

Thanks,
Alissa