Subject: [stir] WGLC: draft-ietf-stir-enhance-rfc8226-00

From: Robert Sparks <[email-masked]>
Date: Mon, 15 Mar 2021 09:49:43 -0500

This a STIR Working Group Last Call for comments on

https://datatracker.ietf.org/doc/html/draft-ietf-stir-enhance-rfc8226-00

Please send your comments to the list or to the chair by 31 Mar, 2021.

We realize there is another LC already in progress, and that we just 
came out of an IETF week. If you need more time to review and comment, 
please let us know.

RjS

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Mar 2021 16:43:20 -0500

Hi,

Here are my WGLC comments. Overall this is in good shape. I have one minor substantive comments and a few mostly editorial comments.

Thanks!

ben.

*Substantive:

It might be helpful to include some guidance about nonsensical combinations. Some combinations can make all passports signed by the cert invalid, for example a mustInclude and mustExclude for the same claim. Some combinations might be pointless, but maybe not break anything, for example non-overlapping permittedValues and excludedValues lists for the same claim.

It would be reasonable to argue that implementors can figure that sort of thing out for themselves, but it rarely hurts to be explicit.

* Editorial (all in §3)

— First sentence: "Certificate subjects are limited to specific values for PASSporT
   claims with the Enhanced JWT Claim Constraints certificate extension;”

I found that clause a bit confusing—at first I thought it was saying that putting claim constrains in passports would limit the values that could go in the subject fields :-) Maybe something like “Certificate issuers can use Enhanced JWT Claim Constraints to limit the claims in PASSporTs signed with the certificate;…"

— List Item 1: "The baseline PASSporT claims ("iat", "orig", and "dest") are considered to be permitted by default…”

Should “permitted” be “required”?

— List Item 2: “ … the claim MUST contain one of the listed values”

Would it make sense to say “… MUST be of one of the listed values”? Otherwise, I wonder if people might decide a value of “foobar” contains “foo”.

— List Item 3: " in addition to the iat, orig, and dest claims.”

Sentence fragment. It seems redundant to the next sentence, so I expect a cut/paste error.

> On Mar 15, 2021, at 9:49 AM, Robert Sparks <[email-masked]> wrote:
> 
> We realize there is another LC already in progress, and that we just came out of an IETF week. If you need more time to review and comment, please let us know.
> 
> RjS
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Mar 2021 18:32:33 -0400

Ben:

Thank you for the careful review.  Your points are all making the document better.

> It would be reasonable to argue that implementors can figure that sort of thing out for themselves, but it rarely hurts to be explicit.

I agree that some guidance is useful, but I'm not sure that I agree with this part:

    Some combinations might be pointless, but maybe not break anything,
    for example non-overlapping permittedValues and excludedValues lists
    for the same claim.

Suppose a claim is currently defined for "1", "2", and "3", and then these values all appear in permittedValues and excludedValues.  If the claim definition is expanded to allow "4", the certificate still works and no one will get surprised.

I suggest this text for the Security Considerations:

   Certificate issuers must take care when imposing constraints on the
   PASSporT claims and the claim values that can successfully validated;
   some combinations can prevent any PASSporT from being successfully
   validated by the certificate.  For example, a mustInclude and
   mustExclude for the same claim will prevent successful validation on
   any PASSporT.

>   claims with the Enhanced JWT Claim Constraints certificate extension;”

I see how that can be too easy to misunderstand.  I suggest:

   The Enhanced JWT Claim Constraints certificate extension limits the
   PASSporT claims and the claim values that can successfully validated
   by the certificate that contains the extension.  Certificate issuers
   permit all claims by omitting the Enhanced JWT Claim Constraints
   certificate extension from the extension field of the certificate
   [RFC5280].  The certificate extension is non-critical, applicable
   only to end-entity certificates, and defined with ASN.1 [X.680].  The
   syntax of the JWT claims in a PASSporT is specified in [RFC8225].

> Sentence fragment. It seems redundant to the next sentence, so I expect a cut/paste error.

These are all good points. I suggest the following for the whole list:

   1.  mustInclude indicates JWT claims that MUST appear in the PASSporT
       in addition to the iat, orig, and dest claims.  The baseline
       PASSporT claims ("iat", "orig", and "dest") are considered to be
       required by [RFC8225], and these claims SHOULD NOT be part of the
       mustInclude list.  If mustInclude is absent, the iat, orig, and
       dest claims MUST appear in the PASSporT.

   2.  permittedValues indicates that if the claim name is present, the
       claim MUST exactly match one of the listed values.

   3.  mustExclude indicates JWT claims that MUST NOT appear in the
       PASSporT.  The baseline PASSporT claims ("iat", "orig", and
       "dest") are always permitted, and these claims MUST NOT be part
       of the mustExclude list.

   4.  excludedValues indicates that if the claim name is present, the
       claim MUST NOT exactly match any of the listed values.

Russ

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Mar 2021 18:26:20 -0500

Thanks for the quick response. Please see inline. Sections with no further comment all look good to me.

Ben.

> On Mar 23, 2021, at 5:32 PM, Russ Housley <[email-masked]> wrote:
> 
> Ben:
> 

How does the addition of “4” change anything if only “1”, “2”, and “3” are in permittedValues? You still can’t set the claim to “4”, since it’s not in the permittedValues list, right? Wouldn’t having the same list in both permittedValues and excludedValues make it impossible to include the claim at all and pass validation? And if the claim is also in mustInclude, you’d be pretty much hosed, right?

The pointless-but-harmless scenario I had in mind was non-overlapping lists. E.g. permittedValues of “1”, and “2”, and an excludedValues of “3”. Since only “1” and “2” are permitted, that seems to exclude everything else, making the exclusion of “3” redundant. For that matter,  Or am I misinterpreting the intent?

Is there really ever a good reason to have both includedValues and excludedValues constraints for the same claim?

>   mustExclude for the same claim will prevent successful validation on

In spite of my comments above, that text looks good to me :-)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Mar 2021 18:41:58 -0500

Hi Russ,

After I sent that reply, I realized I was working under the assumption that claim values are always strings. Is there any prohibition against define a claim with an array value? (I did just a few minutes of digging, and did not come up with a conclusive answer.)

If array values are allowed, would an entry in permittedValues or excludedValues refer to the entire array or an element in the array?

Thanks!

Ben.

> On Mar 23, 2021, at 6:26 PM, Ben Campbell <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Mar 2021 19:12:42 -0500

Continuing to reply to self...

> On Mar 23, 2021, at 6:41 PM, Ben Campbell <[email-masked]> wrote:
> 
> Signed PGP part
> Hi Russ,
> 

On further reflection: Claims can obviously be arrays (e.g dest, mky)
>> On Mar 23, 2021, at 6:26 PM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Mar 23, 2021, at 5:32 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Ben:
>>>

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Mar 2021 22:34:17 -0400

> Is there really ever a good reason to have both includedValues and excludedValues constraints for the same claim?

I cannot think of a situation that would be needed.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Mar 2021 22:37:50 -0400

> If array values are allowed, would an entry in permittedValues or excludedValues refer to the entire array or an element in the array?

I have been thinking of the while claim value since this draft is not changing the permittedValues syntax.  Of course, the lists and arrays, and such are expresses in ASCII.

Russ

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Mar 2021 21:44:15 -0500

> On Mar 23, 2021, at 9:37 PM, Russ Housley <[email-masked]> wrote:
> 
> Ben:
>> 

Good, because I was having trouble getting my head on how this would work if we were talking about constraining individual elements of arrays, etc :-)