Subject: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-enhance-rfc8226-03: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 28 Jun 2021 15:25:38 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-stir-enhance-rfc8226-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-enhance-rfc8226/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Let's discuss whether we should have content in this document discussing
the relationship between this new certificate extension and the
extension defined by RFC 8226.  In paticular, whether it is
permitted/expected for both extensions to appear in the same
certificate, and whether any specific processing is required in that
case.  (If no such processing is specified, we could end up with
interesting edge cases where a given PASSporT is handled differently
depending on which extension(s) are supported by the recipient.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As a standalone description of a certificate extension this document is
in good shape; the main complication that doesn't seem covered is
(per the Discuss) the interaction with the preexisting extension.

Section 3

   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.

If I see one of those claims in the mustExclude list, do I ignore the
entire EnhancedJWTClaimConstraints extension?

       JWTClaimName ::= IA5String

I'd consider a comment that RFC 8226 restricts JWT claim names to be
ASCII.

Section 7

We might mention that since the extension is non-critical, the
additional constraints on validation will only be applied with the
PASSporT recipient implements this extension, and thus that the
constraints might be ignored by some recipients.

   The Enhanced JWT Claim Constraints certificate extension can be used
   by certificate issuers to provide limits on the acceptable PASSporTs
   that will be accepted by verification services.  Enforcement of these
   limits depends upon proper implementation by the verification
   services.  The digital signature on the PASSportT data structure will
   be valid even if the limits are violated.

I'd consider s/will/can/ in the last sentence, as there's no guarantee
that an arbitrary PASSporT signature will be valid.

   Certificate issuers should not include an entry in mustExclude for
   the "rcdi" claim for a certificate that will be used with the
   PASSporT Extension for Rich Call Data defined in
   [I-D.ietf-stir-passport-rcd].  Excluding this claim would prevent the
   integrity protection mechanism from working properly.

I'd consider prefacing this paragraph with something like "For example",
as otherwise one might wonder why this particular claim is so important
to call out in this document's security considerations.

---

From: Russ Housley <[email-masked]>
Date: Mon, 28 Jun 2021 19:18:05 -0400

Ben:

For now, just responding to the DISCUSS ...

I see no reason why both extensions would ever appear in the same certificate.

If there is a mustExclude, then the constraints cannot be expressed in the extension defined in RFC 8226, so I would only expect the on in this document to be present.

If there is not a mustExclude, the the constraints can be expressed in either extension equally well, so I would expect only the extension defined in RFC 8226, with the presumption that it is implemented more widely.

I can add this advice to the document if it resolves your concern.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Jun 2021 22:08:39 -0700

Hi Russ,

> I see no reason why both extensions would ever appear in the same certificate.

There was an open question for me about backwards compatibility...

> If there is a mustExclude, then the constraints cannot be expressed in the extension defined in RFC 8226, so I would only expect the on in this document to be present.

... specifically, if the desired constraints include both mustExclude and
one of the preexisting restrictions, does "something is better than
nothing" apply when the recipient might not implement the new extension,
prompting a desire to include both extensions so that the recipient will
apply those constraints it does know about?

If there is a desire to provide this backwards compatibility, is it better
to duplicate the constraint in both extensions or rely on both extensions
being processed and only put mustExclude in the new extension?  If the
latter, why do we bother allowing the mustInclude and permittedValues forms
in the new extension?

> I can add this advice to the document if it resolves your concern.

I think at least the last bit makes sense to mention in this document.  I'm
still not entirely clear on the full picture, though.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Jun 2021 09:52:00 -0400

> apply those constraints it does know about?

No.  It is important that all of the constraints are met for the use cases where mustExclude come into play.

> latter, why do we bother allowing the mustInclude and permittedValues forms

Indeed,  If that were the case, I think a different design would be preferable.

> still not entirely clear on the full picture, though.

I'll craft some text to address this, and then I will turn to your other comments.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Jun 2021 07:07:24 -0700

> No.  It is important that all of the constraints are met for the use cases where mustExclude come into play.

It seems like that might be worth mentioning as the intended use, as well.

> I'll craft some text to address this, and then I will turn to your other comments.

Sounds good; thanks.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Jun 2021 10:13:53 -0400

> It seems like that might be worth mentioning as the intended use, as well.

I think that the text in Section 1 does that:

   The Enhanced JWT Claim Constraints certificate extension is needed to
   limit the authority when a parent STIR certificate delegates to a
   subordinate STIR certificate.  For example,
   [I-D.ietf-stir-cert-delegation] describes the situation where service
   providers issue a STIR certificate to enterprises or other customers
   to sign PASSporTs, and the Enhanced JWT Claim Constraints certificate
   extension can be used to prevent specific claims from being included
   in PASSporTs and accepted as valid by the PASSporT recipient.

What do you think needs to be added?

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Jun 2021 11:22:04 -0400

Ben:

Turning to the comments ...

Yes.  I'll add a sentence to state that.  I suggest:

       ...  If one of these baseline PASSporT
       claims appears in the mustExclude list, then the certificate MUST
       be treated as if the extension was not present.

> I'd consider a comment that RFC 8226 restricts JWT claim names to be

Okay. I suggest:

   Following the precedent in [RFC8226], JWT Claim Names MUST be ASCII
   strings, which are also known as strings using the International
   Alphabet No. 5 [ISO646].

> constraints might be ignored by some recipients.

I suggest:

   Since non-critical certificate extension are ignored by
   implementations that do not recognize the extension object identifier
   (OID), constraints on PASSporT validation will only be applied by
   relying parties that recognize the EnhancedJWTClaimConstraints
   extension.

FYI, I expect that the [I-D.ietf-stir-cert-delegation] will require implementations of that specification to support this new extension and the original in RFC 8226.

> that an arbitrary PASSporT signature will be valid.

Okay.

> to call out in this document's security considerations.

Rob asked for SHOULD NOT.  And if you look at the structure in [I-D.ietf-stir-passport-rcd], the integrity really does depend on this claim.

Russ

---

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

Based on the comments from Ben Kaduk, I drafted the below guidance to CAs.

> 6.  Guidance to Certification Authorities
> 
>  The EnhancedJWTClaimConstraints extension specified in this document
>  and the JWTClaimConstraints extension specified in [RFC8226] MUST NOT
>  both appear in the same certificate.
> 
>  If the situation calls for mustExclude constraints, then the
>  EnhancedJWTClaimConstraints extension is the only extension that can
>  express the constraints.
> 
>  On the other hand, if the situation does not call for mustExclude
>  constraints, then either the EnhancedJWTClaimConstraints extension or
>  the JWTClaimConstraints extension can express the constraints.  Until
>  such time as the EnhancedJWTClaimConstraints become widely
>  implemented, the use of the JWTClaimConstraints extension may be more
>  likely to be implemented.  This guess is based on the presumption
>  that the first specified extension will be implemented more widely in
>  the next few years.

The delegated certs activities lead to this document in the first place, so it seems appropriate to ask when people think that delegate certificates will be implement?  Will a future version of the delegated certificates document mandate the implementation of the EnhancedJWTClaimConstraints extension?  Do these answers to these questions offer any better guidance than the above?

Russ

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Jun 2021 15:37:17 +0000

I don't know that enhanced constraints need to be coupled that tightly to delegation. When delegation gets approved in the SHAKEN ecosystem (I wouldn't venture when exactly that will be), it would certainly make sense for SHAKEN specs to point to the enhanced constraints, but I'm not sure there's something we need to close in the IETF to make that possible. I think your Section 6 text looks fine. I guess I can also imagine non-delegation cases that could use enhanced constraints in the future as well, so I wouldn't necessarily want to make them so intertwined.

Jon Peterson
Neustar, Inc.

On 6/29/21, 2:34 PM, "stir on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

    
    Russ
    
    _______________________________________________
    stir mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!qpWJJws5s5r7C_Zrbo0SkTb2N7O6rIi1m4H2ESfUWJqjlysUHlPIPs3FWPg$

---

From: Chris Wendt <[email-masked]>
Date: Wed, 30 Jun 2021 11:58:36 -0400

Yes ATIS-1000092 already says MUST to supporting EnhancedJWTClaimConstraints extension, so i think we are good.

-Chris

> On Jun 30, 2021, at 11:37 AM, Peterson, Jon <jon.peterson=[email-masked]> wrote:
> 
> 
> On 6/29/21, 2:34 PM, "stir on behalf of Russ Housley" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
>   https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!qpWJJws5s5r7C_Zrbo0SkTb2N7O6rIi1m4H2ESfUWJqjlysUHlPIPs3FWPg$ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!qpWJJws5s5r7C_Zrbo0SkTb2N7O6rIi1m4H2ESfUWJqjlysUHlPIPs3FWPg$> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 Jun 2021 12:27:42 -0400

Thanks Jon.

I understand that the EnhancedJWTClaimConstraints extension will support certificate delegation as well as other things.  In an 0ff-list message, I learned that the ATIS will be mandating support for the EnhancedJWTClaimConstraints extension in one of their documents.  So, this approach seems to be on target.

Russ