search

ietf-rats-wg / eat

Entity Attestation Token IETF Draft Standard
Other
18 stars 15 forks source link

Modification of detached Claim-Sets #462

Closed steven-bellock closed 2 months ago

steven-bellock commented 3 months ago

Detached Claims-Sets must not be modified in transit, else validation will fail.

Should that must not be a MUST NOT? If not can it be re-worded to avoid (somewhat) normative language. Maybe something like

If detached Claims-Sets are modified in transit then validation (will / can) fail.

laurencelundblade commented 3 months ago

Good point. I like the rewording. Probably wait until other editorial stuff hits before publishing a new draft.

Thx.

gmandyam commented 3 months ago

The text as it stands is in-line with RFC 2119 requirements on 'MUST NOT' (https://datatracker.ietf.org/doc/html/rfc2119#section-2), given the additional recommendation to use such prohibitions sparingly (https://datatracker.ietf.org/doc/html/rfc2119#section-6), particularly related to the guidance "they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm".

Rather, guidance in the Security Considerations section of EAT (https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-30#name-detached-eat-bundle-dige) currently covers the issue of modification of the claims set in transit. Given that the verifier should be able to detect a modification of the claims set when in transit, it is unclear whether a MUST NOT provision is actually required to allow for "interoperation" or to prevent "causing harm".

We can go with the re-wording as proposed with little-case 'can' fail. Whether it 'will' fail is up to the verifier's appraisal policy.