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

["Murray S. Kucherawy" <[e-mail]>]

Thanks, that's the discussion I wanted to have.  I'll send it off to Last
Call.

On Tue, Sep 27, 2022 at 9:52 AM <[e-mail]> wrote:

> 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] 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]> *On Behalf Of *Murray S. Kucherawy
> *Sent:* Monday, September 26, 2022 10:36 PM
> *To:* Chris Wendt <[e-mail]>
> *Cc:* IETF STIR Mail List <[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]>
> 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
>
>
>