Re: [stir] AD Evaluation: draft-ietf-stir-passport-rcd

[Chris Wendt <[e-mail]>]

> On Sep 26, 2022, at 9:36 PM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> On Mon, Sep 26, 2022 at 2:21 PM Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote:
> > How do we know that the reason placed in a "crn" claim is true?  Could this be abused?  If so, should this be called out in Section 13 or 18 (or somewhere else)?
> 
> Section 8.1 was intended to address this use of constraints if the signer is “non-authoritative”.  The general concept is that RCD information should be vetted by trusted participants in the eco-system.  “crn” is a claim that i think we conceptually provide a bit more latitude with just because call reason may more generally be a more dynamic field, but there is nothing in the specification that doesn’t allow for an eco-system using this specification to mandate the use of constraints.  This is a balance we have needed to support for most of the specs to allow for flexibility depending on use of the specs.
> 
> I'm not sure I follow.  The question I'm asking is: Is there anything stopping me from giving a false reason in a "crn" claim?  Could I, for instance, claim the call is an emergency of some type and thus get you to answer when I'm actually just going to try to sell you something? 

The specific answer to your question is it depends on who “me” is.  If the signer is “authoritative” and responsible for the vetting their own set of “rcd” claims, then yes they can lie about any of the claims, but generally if you do that, whether “crn” or telephone number or calling name, you can be identified as doing fraudulent things and depending on policy be kicked out of the eco-system.

If there is a delegation relationship where the authority is providing certificates with constraints/integrity on what the delegated party can sign for in their “rcd” based on vetting of allowed “rcd” claims, than the constraints prevent the delegated party from putting in “crn” or other claims that contain false or fraudulent information.

> If that's a risk, I think that should be explicit; it would be enough to say that there's no validation for what's in the "crn" claim (and couldn't possibly be).

I guess what i’m saying in too many words is that “crn” follows the same trust model that all of the other claims follow in STIR, so if someone falsifies any information, it’s the signer and/or the authoritative vetter of the information that is responsible party.

So, i guess i’m a little afraid of trying to state in any more explicit way that the trust model is different for “crn”, even though as i state above in my previous response that “crn” is likely to have more variations of text than other signed information and a little more burdensome if vetting/certificate generation is required.  I think all of these things are decisions that have to be made on a eco-system/policy/implementation basis.  But i think all of the rules for “rcd” more generally support the different security policies needed to either have explicit control over “crn” or other claims included in “rcd” PASSporT if required, or make it looser for other more trusted environments.

Hopefully that makes it a bit clearer?  It really is sort of the point of the different constraint and integrity options to enforce “rcd” information, so i want to make sure that its consistent for all information and we generally don’t treat any particular claims differently (at least that wasn’t the intent).


> 
> [...]
> 
> > For that matter, would ABNF be useful here?
> 
> Likely would but we haven’t included it in other relevant specs, i would hate to add at last minute.
> 
> I don't mind waiting if it's worth doing.  :-)

I think for this hyphen case you have called out, its straight forward enough from the description that i don’t need to include.  The example is also pretty illustrative as well.

> 
> Thanks for the rest, looks good.
> 
> -MSK