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

[[e-mail]]

You are correct, I did mean security considerations, Section 18 (not 8.1).  Nice catch.  And as you say “out-of-scope” language is already there.

 

 

From: Chris Wendt <[e-mail]> 
Sent: Tuesday, September 27, 2022 11:35 AM
To: <[e-mail]> <[e-mail]>
Cc: Murray S. Kucherawy <[e-mail]>; IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] AD Evaluation: draft-ietf-stir-passport-rcd

 

I agree Pierce, the first paragraph of the security considerations section does have text to say that content validation/vetting policies are out of scope specifically.

 

-Chris





On Sep 27, 2022, at 8:15 AM, [e-mail] <mailto:[e-mail]>  wrote:

 

IMHO, validation of content in icn, crn, nam, etc., is outside the scope of the RCD specification.  Perhaps that should be (part of) the message in Section 8.1?

 

Pierce

 

From: stir <[e-mail] <mailto:[e-mail]> > On Behalf Of Murray S. Kucherawy
Sent: Monday, September 26, 2022 10:36 PM
To: Chris Wendt <[e-mail] <mailto:[e-mail]> >
Cc: IETF STIR Mail List <[e-mail] <mailto:[e-mail]> >
Subject: Re: [stir] AD Evaluation: draft-ietf-stir-passport-rcd

 

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

 

[...]

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

 

Thanks for the rest, looks good.

 

-MSK