Re: [stir] Malformed PASSporTs

[Chris Wendt <[e-mail]>]

Hi Jack,

Generally, we do have MUST level requirements for the defined claims in RFC8225, for example, MUST be canonicalized according to RFC8224 for “orig".  And as you point out, if there is claim keys that aren’t defined or are not understood by the implementation they should be ignored.
Let me look specifically at all of your cases and see if there is anything missing, but above is the general intent.  Note that SHAKEN specs to provide additional guidance, but this is above and beyond the basics of JSON rules and the specific claim guidance.

-Chris

> On Jan 14, 2022, at 11:28 AM, Jack Rickard <jack.rickard=[e-mail]> wrote:
> 
> Hi all,
>  
> What’s the intended behaviour of a verification service when it encounters a PASSporT with badly formed claims, but is otherwise valid?
>  
> There’s a progression of possibilities here which range from being able to do nothing to being entirely ignorable. I’m worried there are interop or security issues I haven’t thought of with being maximally permissive.
>  
> Fundamental field totally invalid
> “orig”: [2]
> It’s impossible to validate this passport no matter how lenient you are as there’s no way to verify this against the From header.
> Fundamental field partially invalid
> “dest”: { “tn”: [“12345556789”], “uri”: 6 }
> Theoretically you could validate this passport if the INVITE was to 12345556789, however processing this would be awkward, and for the sake of the ecosystem it may be better to reject it.
> Extra field invalid
> “ppt”: ”rph”, “rph”: “invalid”
> This is not a useable RPH passport but could degrade to a base passport and provide some authority. RPH may be a bad example because I’m not sure it’s meant to attest to the caller, however if the ppt field was malformed you wouldn’t know that…
> Optional field invalid
> “ppt”: “shaken”, “rcd”: {}
> The field isn’t mandatory, nor is it the primary focus of this passport. Ignoring the “rcd” field would do very little harm, bar allowing dodgy implementations to proliferate.
> Unnecessary non-STIR field invalid
> “aud”: 6
> I doubt many STIR implementations even check if non-STIR fields exist, let alone whether they have the right type. Completely ignoring this feels like the right thing to do, however rejecting it would also be reasonable, if everyone agreed.
> Although, not checking this specific field is in violation of the JWT standard, so maybe this should be rejected?
> Completely unexpected field
> “foo”: “bar”
> AS this is JSON I’m pretty sure this should be accepted and ignored.
>  
> I haven’t been able to find much in the standards addressing this, so I’m interested to know your opinions. I’ve been unable to come to much of an opinion myself, being permissive feels sensible, but could have negative effects on the ecosystem and generally raises more questions than answers. Being draconian is probably simplest, but could cause interop problems, especially as things change.
>  
> Thanks,
> Jack Rickard 
> he/him 
> Software Engineer 
> [e-mail] <mailto:[e-mail]> 
> 
> <image001.png>
>  
>  
> _______________________________________________
> stir mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>