Re: [stir] Malformed PASSporTs

[Chris Wendt <[e-mail]>]

Yeah i think Alec, you have captured the general intent. 

> On Jan 14, 2022, at 2:33 PM, Alec Fenichel <alec.fenichel=[e-mail]> wrote:
> 
> As an implementer, I generally prefer being permissive about unknown fields and draconian about known fields. Put another way, we are looking for specific fields. We expect these fields to follow the required format. If they don’t, we will reject the PASSporT. If there are extra fields that we aren’t explicitly looking for, they are completely ignored, so they can be invalid. Note “rcd” is a known field, it doesn’t matter what the ppt is, if you include “rcd”, it needs to be properly formatted.
>  
> Sincerely,
>  
> Alec Fenichel
> Senior Software Architect
> [e-mail] <mailto:[e-mail]>
> [phone]
> TransNexus
>  
> From: stir <[e-mail] <mailto:[e-mail]>> on behalf of Jack Rickard <jack.rickard=[e-mail] <mailto:jack.rickard=[e-mail]>>
> Date: Friday, January 14, 2022 at 11:29
> To: IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> Subject: [stir] Malformed PASSporTs
> 
> 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[37].png>
>  
>  
> _______________________________________________
> stir mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>