Subject: [stir] WG Last Call Comments: draft-ietf-stir-passport-divert-05

From: Russ Housley <[email-masked]>
Date: Mon, 15 Apr 2019 11:03:21 -0400

Document: draft-ietf-stir-passport-divert-05
Reviewer: Russ Housley
Review Date: 2019-04-15

Major:

Section 1: The last paragraph introduces the "div" PASSporT type.  In
another document, IANA got confused when the "type" was not aligned with
the names used for the registries.  Looking at the structure of RFC 8225,
I think that "div" is a PASSporT Header Parameter value.  Please reword
to provide clarity.  Also, later in the document, "div" PASSporT is used
as shorthand.  This seems very useful.  I suggest this be defined in
Section 1 and used consistently in the document.

Section 1: Please provide similar clarity for the separate "div-o"
PASSporT type and "opt" PASSporT element.  Defining a "div-o" PASSporT
in Section 1 would also help the reader.

Section 3: The first paragraph points out that a new PASSporT is only
necessary when the canonical form of the "dest" identifier (per the
canonicalization procedures in [RFC8224] Section 8).  This seems like
a place for a MUST NOT statement.  If the canonical form of the "dest"
identifier is unchanged, then a new PASSporT with a "div" claim MUST
NOT be produced.

Section 3: The text talks about the PASSporT claims object.  I think
this is the PASSporT Payload as described in Section 5 of RFC 8225.
Please use the same terms.  Similarly, the last paragraph should say
that the PASSporT Payload of a "div" PASSporT MUST NOT contain an
"opt" claim.

Section 5: This section also text talks about the PASSporT claims object.
As above, I think this is the PASSporT Payload as described in Section 5
of RFC 8225.

Section 10: As I said above, in another document, IANA got confused when
the "type" was not aligned with the names used for the registries.  This
can be avoided by providing the URL for the intended registry in each
subsection.

Minor:

Section 1: The second paragraph says: "... it also provides a signature
over the called number as the authentication service sees it."  I think
the point is to authenticate the intended recipient, not just provide
visibility.

Section 2: Please update the first paragraph to reference RFC 8174
in addition to RFC 2119, as follows: 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
   
Of course, also add a normative reference to RFC 8174.

Examples of "x5u" claims use the .pkx file extension.  Please use .cer
to align with the conventions in RFC 2585.

Nits:

The document uses 'div' and "div".  It also used 'dest' and "dest".
Please pick one convention, and then use it throughout the document.

Suggestion for the start of the Abstract: "This document extends
PASSporT, which is specified in RFC 8224 to convey cryptographically-
signed ..."

The 'Updates' line in the title page header should list only the numbers
of the to-be-updated RFCs (if approved).

Outdated reference: draft-ietf-stir-rph has been published as RFC 8443.
Please update the reference.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 15 Apr 2019 19:14:55 +0000

Thanks for the notes Russ. Some responses inline.
    
    Major:

PASSporT Type ("ppt") is defined in RFC8224 Section 4. Its use is consistent with the terminology in the IANA Considerations of RFC8225 (Section 11.4) which formally names that registry the "PASSporT Extensions Registry." I'll clarify that we mean this registry in the IANA Considerations of the stir-passport-divert spec (and add the URL of the registry as you suggest below), but I think it's okay if we keep using the terminology "PASSporT Type".

No problem, will add that.
    
    Section 3: The text talks about the PASSporT claims object.  I think
    this is the PASSporT Payload as described in Section 5 of RFC 8225.
    Please use the same terms.  

Well, the "header" and "claims" terminology is from the JWT RFC (7519), "payload" comes from the core JWS RFC (7515). They are kind of used interchangeably around the STIR specs; there are plenty of references to claims in RFC8225. I think I'm okay with continuing to use "payload" and "claims" to mean the same thing.

    Similarly, the last paragraph should say
    that the PASSporT Payload of a "div" PASSporT MUST NOT contain an
    "opt" claim.

Probably that's fine. I'm idly wondering if some other PASSporT extension might want to use "opt" in conjunction with "div" for some reason. Seems unlikely, and we could just leave it to any future extension to patch this later if needed.
        
    Minor:

"as the authentication service sees it" there is not about visibility, it's referring to the fact that the intended recipient may change in flight - the authentication service sees it before those changes.

       
    
Will do.

Will do. And will do those nits below, with my one note there...
    
    Nits:

I thought we weren't supposed to put references in the abstract (apart from notes about RFC obsoleted etc. by this spec).

    
Jon Peterson
Neustar, Inc.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 15 Apr 2019 14:37:21 -0500

trimming to one thing in the nits:

> I thought we weren't supposed to put references in the abstract (apart from notes about RFC obsoleted etc. by this spec).

We aren't allowed to use references in the [see the references section] 
sense. It's perfectly fine to name other RFCs.

RjS

>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Apr 2019 15:44:37 -0400

Jon:

Minor follow up...

> PASSporT Type ("ppt") is defined in RFC8224 Section 4. Its use is consistent with the terminology in the IANA Considerations of RFC8225 (Section 11.4) which formally names that registry the "PASSpo…

Yes, I agree that "PASSporT Type" is fine as long as Section 10 has the right pointer.

> Well, the "header" and "claims" terminology is from the JWT RFC (7519), "payload" comes from the core JWS RFC (7515). They are kind of used interchangeably around the STIR specs; there are plenty o…

My reading of RFC 8225 is that the payload is composed of a collection of claims.  Some of the claims are defined in the JWT specifications, and other are defined specifically for PASSporT.  In the document, it is not clear to me whether a "claim object" is one of the claims in this collection or the whole collection.  If the term payload was used for the whole collection, I think it would be more consistent and clear.

> Probably that's fine. I'm idly wondering if some other PASSporT extension might want to use "opt" in conjunction with "div" for some reason. Seems unlikely, and we could just leave it to any future…

The document already says otherwise:

   PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6)
   element in their claims; PASSporTs of type "div-o" (see Section 5)
   MUST contain an "opt".

It does not say whether for future type "foo" can use it or not, which seems appropriate.

Russ

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 16 Apr 2019 16:39:03 +0000

<Russ> My reading of RFC 8225 is that the payload is composed of a collection of claims.  Some of the claims are defined in the JWT specifications, and other are defined specifically for PASSporT.  In the document, it is not clear to me whether a "claim object" is one of the claims in this collection or the whole collection.  If the term payload was used for the whole collection, I think it would be more consistent and clear.</Russ>

I agree that we don't want that ambiguity about whether the "claims object" refers to a single claim or the set of claims. I guess I am a little hesitant to require that we use the JWS term "payload" for this, though, because looking through the RFCs JWT seems to favor the term "claims set". I don't want to get too pedantic about this, but maybe I can remove "claims object" in favor of using either "payload" or "claims set" where their semantics seems to fit?

Jon Peterson
Neustar, Inc.

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Apr 2019 14:58:23 -0400

> I agree that we don't want that ambiguity about whether the "claims object" refers to a single claim or the set of claims. I guess I am a little hesitant to require that we use the JWS term "payloa…

That would totally resolve my concern.

Russ