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

[Ben Campbell <[e-mail]>]

(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 <[e-mail]> 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
>