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

[Russ Housley <[e-mail]>]

Ben:

Turning to the comments ...

> ----------------------------------------------------------------------
> 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?

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.

> 
>       JWTClaimName ::= IA5String
> 
> I'd consider a comment that RFC 8226 restricts JWT claim names to be
> ASCII.

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].

> 
> 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.

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.

> 
>   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.

Okay.

> 
>   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.

Russ