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

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Jul 2021 08:55:44 -0500

(as draft shepherd)

Hi Ben,

Russ submitted an update yesterday (04) that I _think_ covers  your DISCUSS and COMMENT points.

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

Thanks!

Ben C.

> On Jun 29, 2021, at 9:07 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> On Tue, Jun 29, 2021 at 09:52:00AM -0400, Russ Housley wrote:
>> 
>> Ben:
>> 
>>>> For now, just responding to the DISCUSS ...
>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> 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.)
>>>> 
>>>> 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?
>> 
>> 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.
> 
>>> 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?
>> 
>> Indeed,  If that were the case, I think a different design would be preferable.
>> 
>>>> 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.
>>> 
>>> 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.
>> 
>> I'll craft some text to address this, and then I will turn to your other comments.
> 
> Sounds good; thanks.
> 
> -Ben
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 3 Jul 2021 10:54:54 -0700

Hi Russ,

On Tue, Jun 29, 2021 at 10:13:53AM -0400, Russ Housley wrote:
> 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?

It has become much less important now that the two extensions MUST NOT
both appear in the same certificate, since that has implicitly made a value
judgement on the importance of supporting all of the constraints
simultaneously.

But the quoted text from Section 1 seems to only say that there is a need
to use this extension for the delegation case (for the new behavior); it
seems indifferent on whether it's important to have all the constraints
together so that either all the constraints are applied or none are.  Just
based on this description, it would be just as effective to put the new
constraint in the new extension and put the other constraints in the
preexisting extension.  Obviously that's not possible given the "MUST NOT
both appear", so I'm not going to push for additional text on this point.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 3 Jul 2021 10:58:10 -0700

Hi Russ,

Trimming the bits that look good...

On Tue, Jun 29, 2021 at 11:22:04AM -0400, Russ Housley wrote:
> Ben:
> 
> Turning to the comments ...
> 
> > COMMENT:
[...]
> > Section 7
[...]
> >   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.
> 
> 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.

Yes, it's clear that the integrity of RCD does depend on the claim in
question.
It's less clear that enhance-rfc8226 is the best place to make that
restriction, which could also be imposed by draft-ietf-stir-passport-rcd
itself.  In short, "why is this claim so important that it gets called out
by name in an otherwise generic specification?".

What's in the document now is factually correct, so I don't mind having it
there; it just seems a little surprising to call out one specific external
claim and not say why only that one is mentioned.

Thanks again for all the updates,

Ben

---

From: Russ Housley <[email-masked]>
Date: Sat, 3 Jul 2021 14:24:02 -0400

> claim and not say why only that one is mentioned.

That was my reason for the original wording.  However, as you say, having both this document and draft=ietf-stir-passport-rcd make this statement is not really a problem.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 3 Jul 2021 14:27:37 -0400

> both appear", so I'm not going to push for additional text on this point.

Delegation is the use case that caused this to be written now, but it is unclear whether other situations will make use of this capability.

Since this thread started, Chris Wendt shared with the STIR WG that an ATIS document is mandating implementation of The Enhanced JWT Claim Constraints certificate extension, so I think we will be in a good place.

Russ