Skip to content

Ionut’s review #69

@thomas-fossati

Description

@thomas-fossati

Archived-at: https://mailarchive.ietf.org/arch/msg/rats/KYpUqk9qnp_3eLmw7dtg0W4P4jc/

The main points:

  • There are a few abbreviations not expanded in the abstract. Also, the abstract and the introduction seem to be literally the same content, with some extra references added. Expanding the intro a bit would be useful to people new to the topic.

  • In section 3, in the description of ear.status, you note: " The value of this claim MUST be set to a tier of no higher trust than the tier corresponding to the worst status claim across all EAR appraisal submods." This seems like a judgement on what appraisal policies can and cannot encode - which is fair enough, but I wanted to confirm your reasoning here. Mainly, I was curious if components about which the policy doesn't care are just expected to not appear in the EAR. More concretely, if the policy says "yeah, this sub attester might be in a 'bad' state, don't care", how would that affect this top-level status?

  • In section 4.5, for ear_veraison_key_attestation could you provide more context, or perhaps a reference to key attestation?

  • In section 8, it would be useful to give some examples for (or more details about) how redaction and/or anonymisation of claims might be achieved. Regarding "outright removal", I was considering the potential benefit for having a standardised way of communicating "removal". Something like a "this page is intentionally left blank" for EAR claims. Something else I was wondering was the option of having a key ID claim if some of the claims (ear_raw_evidence?) need to be encrypted for privacy. But these are fairly random suggestions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions