Re: [SCITT] Internet-Draft draft-ietf-scitt-architecture-05.txt

[Robin Bryce <[e-mail]>]

Hi all,

Thanks for all the work that went into the new draft. I have some feedback & questions.

4.1.1 Initialization


This appears to prescribe the precise contents of the initial log entries in the name of solving a verification problem - that the statement verification requires a trust anchor in order that verification can be successful.

I don't understand why the trust anchor needs to be in the log in a particular position. Verification is just contingent on is availability. I also don't understand why it needs to be in the same log or any particular log at all.

It creates significant operational problems inserting these sorts of requirements, and it’s very intrusive with regards the log itself.

I think this section implies that an Issuer can submit a Registration Policy to self-attest its keys and scope of use and that becomes the thing the Transparency Service later verifies against? If that really is desired, then I think the last paragraph "This specification leaves implementation, encoding and documentation of Registration Policies to the operator of the Transparency Service" leaves scope for implementors to support that.

Precisely how registration policies are established ought to be the business of the individual log implementation.

4.1.2 Registration

Re: 2.

"Issuer Verification: The Transparency Service MUST perform resolution of the Issuer's identity. This step may require that the service retrieves the Issuer ID in real-time, or rely on a cache of recent resolutions. For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache."

A requirement to verify issuer identities in real time does not guarantee that maliciously or mistakenly signed items will not reach the log. Compromise of the identity may be discovered after the statement has been accepted on the log, and then we are no better off than had we simply relied on cryptographic verification. It is always going to be down to auditors, verifiers, and log consumers in general, to use the attested data to reach their own conclusions. And those conclusions may well change over time.

Having this as a requirement does not help solve these problems, it complicates the implementations, and it will be a significant performance bottle neck.

Deferring id verification to the point at which a receipt is asynchronously requested could be a workable compromise.

Secondly, it is far from clear what "evidence of the lookup, including if it was resolved from a cache" would look like in the real world. I don't think it is feasible for SCITT to specify that in detail. So the requirement is very ambiguous.

Re: 7

Receipts should be an optional part of the registration process. There exist verifiable data structures which enable receipts to be generated in the future which are provably identical to the receipt that would be issued at the time of registration. Decoupling these allows for higher volume use cases where receipts aren’t desired for all statements, or at least not desired immediately. This rests on the ability of the log implementation to provide tamper evidence and provable log consistency. There are efficient ways to batch proof (and hence receipt generation), that would be un-usable if a receipt is a required part of the registration process.

The wording in the Registration section isn't super clear about if and how this sort of batching is accommodated.

"A Transparency Service MUST ensure that a Signed Statement is registered before releasing its Receipt" this means the log entry for the signed statement must be committed to the log before the receipt can be created. That log entry itself cannot be a transparent statement because the receipt is its inclusion proof in the log. I think this is probably obvious, but some of the wording could imply the transparent statement is a log entry.

The wording at the start of 4.3 is much clearer in this regard.

4.2 Signed statements

"Support for x5t is mandatory to implement" Why is this helpful ? If I use a cnf claim and an iss to fetch an openid connect style well known document over https and then check the kid and public key match what is in the claim, don't I, as a transparency service implementor, get all the benefits of TLS certificates without exposing the implementation to the burden of x509 verification ? And that TLS certificate & its verification may well be backed by a transparency service in the full ness of time, but it’s actually more robust if its independent and opaque.

Surely it is sufficient to say implementations MUST implement either x5t or kid/cnf ? Is there a thread or reference somewhere I can read to catch up with the arguments either way on this ?

4.3 Transparent Statements

"Receipts are based on Signed Inclusion Proofs as described in COSE Signed Merkle Tree Proofs" I understood merkle based logs were one of the options and that the standard wasn't fixing on merkle based logs. Is this still the intent ?

4.3.1 Validation

"In order to verify the inclusion proof that is included in the Receipt, the verification process for the inclusion proof MUST be performed as described in the document that registers corresponding Verifiable Data Structure Parameters https://www.ietf.org/archive/id/draft-ietf-scitt-architecture-05.html#I-D.draft-steele-cose-merkle-tree-proofs"

This is a useful and helpful draft, but it only contains RFC9162_SHA256 in its registry. What should implementations do in advance of being able to register here ?

7.2.6 Impersonation

"It is up to the Issuer to notify Transparency Services of credential revocation to stop Verifiers from accepting Signed Statements signed with compromised credentials" this means the guarantee isn't terribly useful. It’s always going to require after the fact retrospective analysis to figure out which statements were recorded while the identity was unknowingly compromised. The guarantee is misleading. It is sufficient to guarantee that the identity presented at the time of the statement is evident in the log.

Hope this is useful and constructive. Thanks again for the great work!