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

[Dick Brooks <[e-mail]>]

Well done, Robin. Methodical analysis and valuable insights.

 

I think we may have had a similar response to the latest draft architecture.
IMO, it does seem to delve into implementation details regarding the way in
which logging must be performed by the registry. 

 

The precise way in which a Registry Operator implements its logging process
and other registry operations should not be a concern that demands a
prescriptive implementation process in SCITT; the implementation does not
impact interoperability with Issuers or others that wish to access trusted
statements via the interfaces provided by the Registry operator. The API's
need to be prescriptive in order to ensure interoperability, but the
internal process used by the Registry Operator does not need to have a
prescriptive process, but the process must follow high integrity policies
and principles, defined by the SCITT architecture, to ensure that the all
interactions with the "Trust Registry" (Transparency Service) are considered
trustworthy in order to be considered a trusted "trust anchor".

 

The Registry Operator should be expected to follow certain policies and
principles that will ensure the integrity and trustworthiness of the "Trust
Registry" process and the data that is exchanged with the Transparency
Service and its users.

 

IMO SCITT needs to precisely prescribe the interfaces that will ensure
interoperability between Issuers, Verifiers/Consumers and other users with
the Registry operator Transparency Service. 

 

The Registry Operator is expected to follow SCITT defined policies and
practices that will ensure the use of high integrity processes that are
needed to ensure that the "Trust Registry", it's data and all interactions
between the Registry Operator Transparency Service and users remains trusted
by all users, throughout its existence by providing evidence of adherence to
the SCITT policies and principles defined in the architecture document. 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

Never trust software, always verify and report!
<https://reliableenergyanalytics.com/products>  T

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: [e-mail]
<mailto:[e-mail]> 

Tel: [phone]

 

 

From: SCITT <[e-mail]> On Behalf Of Robin Bryce
Sent: Monday, February 12, 2024 3:00 AM
To: [e-mail]
Subject: Re: [SCITT] Internet-Draft draft-ietf-scitt-architecture-05.txt

 

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.dr
aft-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!