Re: [stir] draft-ietf-stir-passport-rcd-04

[Chris Wendt <[e-mail]>]

Hi Russ,

I may have not included ordering of claim, but intended to or maybe assumed that default PASSporT serialization rules applied in either case, let me review again.  I plan to provide a cleaned up version and go through Eric’s comments provided at last meeting hopefully by end of week and can updated that.

-Chris

> On Sep 9, 2019, at 2:45 PM, Russ Housley <[e-mail]> wrote:
> 
> Based on Ben's recent questions, I read draft-ietf-stir-passport-rcd-04, and I am concerned about the integrity mechanism.
> 
> First, as silly editorial comment.  The example at the end of Section 4.1.1 is:
> 
>    "rcd": { "nam" : "James Bond",
>             "icon" : "https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>"
>           }
> 
> Based on Section 3.2, I think this should be "icn".
> 
> Now, my more substantive concern.
> 
> What order must the claims appear?
> 
> Consider this example:
> 
>    "rcd": { "nam" : "James Bond",
>             "icn" : "https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>",
>             "jcl" : "https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>"
>           }
> 
> This will produce an rcdi that contains the hash of:
> 
>    {"nam":"James Bond","icon":"https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>", "jcl":"https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>"};
>    BASE64(WGET(https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>));BASE64(WGET(https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>))
> 
> On the other hand, this rcd:
> 
>    "rcd": { "nam" : "James Bond",
>             "jcl" : "https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>",
>             "icn" : "https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>"
>           }
> 
> This will produce an rcdi that contains the hash of:
> 
>    {"nam":"James Bond","icon":"https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>", "jcl":"https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>"};
>    BASE64(WGET(https://example.org/james_bond.jcard <https://example.org/james_bond.jcard>));BASE64(WGET(https://example.org/james_bond.jpg <https://example.org/james_bond.jpg>))
> 
> I think it would be cleaner if there were a specific ordering (maybe alphabetical by the claim key) to eliminate any possibility surprises.
> 
> 
>>>> 
>>>> 1) Do I understand correctly that the certificate used to sign a PASSporT with an rcdi claim MUST include a constraint for the _value_ of the digest? That is, if someone makes any change to any of the information they would normally include in an rcd claim, the signing party must get a new cert?
> 
> I think that Ben is talking about this text:
> 
> 4.2.  JWT Constraint for "rcdi" claim
> 
>    Once both the contents of the "rcd" claim is certified and the
>    construction of the "rcdi" claim is complete, the "rcdi" digest is
>    linked to the STIR certificate associated with the signature in the
>    PASSporT via JWT Constraints as defined in [RFC8226] Section 8.
> 
>    The certificate JWT Constraint MUST include both of the following:
> 
>    o  a "mustInclude" for the "rcd" claim
> 
>    o  a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
>       to the created "rcdi" claim value string.
> 
> The "permittedValues" part of the last bullet seems like overkill.  I like the a "mustInclude" for the "rcdi" claim, but signing over the digest as computed in Section 4.1.1 should eliminate any surprises.  Putting those have values into the certificate seems like the lifespan of the certificate will be greatly reduced.
> 
> Russ
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir