Role of Trust Anchors - Githubissues

ietf-wg-scitt / draft-ietf-scitt-architecture

An Architecture for Trustworthy Digital Supply Chain Transparency Services

Other

11 stars 15 forks source link

Role of Trust Anchors #270

Closed hannestschofenig closed 1 month ago

hannestschofenig commented 3 months ago

Editors note: updated with a link to the referenced text:

Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement.

I don't understand the SHOULD.

You have to be in possession of trust anchors to verify a digital signature. It is not an optional feature.

aj-stein-nist commented 3 months ago

I don't understand the SHOULD.

You have to be in possession of trust anchors to verify a digital signature. It is not an optional feature.

It would seem this is correct contingent on your interpretation of the requirements of TS registration steps, especially, particularly points 2 and 3, so good point.

robinbryce commented 3 months ago

It's not the use of the anchor in verifying that is optional. It is the use of issuer verification as a gate to registration that is the problem.

For ts implementations that naturaly have RBAC at the edge, the "spam" problem is not really a problem.

Statements about statements seem to me to be a better way to deal with use cases where strong issuer verification is necessary. Registration time checks can only ever be "point in time"

SteveLasker commented 1 month ago

My read of the Issue and the current state of the document is:

This section is under Registration Policies, which implies the MUST refers to enabling the registration process. Currently, a registration can not be completed unless the issuer is verified, which can't occur without trust anchors. The SHOULD refers to verifiers which are not part of the Registration Policy. I think their inclusion in this section is confusing.

See #304 for a proposal.