iat content based on PASSporT issuance time Conflict Analysis against RFC8224 / ATIS-1000074

RFC8224 4.1 PASSporT Construction 6.2 Verifier Behavior Third, the JSON key "iat" MUST appear. The authentication service SHOULD set the value of "iat" to an encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519], Section 2), though an authentication service MAY set the value of "iat" to its own current clock time. If the authentication service uses its own clock time, then the use of the full form of PASSporT is REQUIRED. In either case, the authentication service MUST NOT generate a PASSporT for a SIP request if the Date header is outside of its local policy for freshness (sixty seconds is RECOMMENDED). Using local clock time as “iat” content is allowed if full form is used 6.2 Verifier Behavior Step 4: Check the Freshness of Date The verifier furthermore ensures that the value of the Date header field of the request meets local policy for freshness (sixty seconds is RECOMMENDED) and that it falls within the validity period of the credential used to sign the Identity header field. For more on the attacks this prevents, see Section 12.1. If the full form of the PASSporT is present, the verifier SHOULD compare the "iat" value in the PASSporT to the Date header field value in the request. If the two are different, and the "iat" value differs from the Date header field value but remains within verification service policy for freshness, the verification service SHOULD perform the computation required by Step 5, using the "iat" value instead of the Date header field value. For full form, “iat”, Date header content being different is allowed That “iat” passes freshness check is sufficient

ATIS-1000074 5.3.1 PASSporT & Identity Header Verification The verifier validates that the PASSporT token provided in the Identity header of the INVITE includes all of the baseline claims, as well as the SHAKEN extension claims. The verifier shall also follow the draft-ietf-stirrfc4474bis-defined verification procedures to check the corresponding date, originating identity (i.e., the originating telephone number) and destination identities (i.e., the terminating telephone numbers). Follows RFC8224, no new mandates regarding date check 5.3.3 Use of the Full Form of PASSporT Draft-ietf-stir-rfc4474bis supports the use of both full and compact forms of the PASSporT token in the Identity header. The full form of the PASSporT token shall be used to avoid any potential SIP network element interaction with headers, in particular the Date header field, which could lead to large numbers of 438 (‘Invalid Identity Header’) errors being generated. Use of full form mandated