Re: [SCITT] Should verification keys go onto the transparency log

[Henk Birkholz <[e-mail]>]

On 05.03.24 08:15, Robin Bryce wrote:
>> TBH given that receipts are already divided by which verifiable data 
> structures are supported, I think it's fair to say
> 
>> that SCITT does not work without agreeing to a profile, which at a minimum restricts the verifiable data structures.
> 
>> Perhaps that profile is where the Policy constraints belong, and not in 
> the architecture.
> 
> That makes a lot of sense to me. It sounds like the choice for the arch is:
> 
> a) Accept a very prescriptive approach, and be “one and done” subject to 
> agreeing the prescriptions.
> 
> b) Decide that profiles are made possible by the current text and, 
> especially, their minimum mandatory requirements. And be essentially all 
> good ?

The current slimmed down architecture I-D is exactly going down path b), 
I think. "Profiling" can also have an effect on the higher API layers 
and we can discuss that at IETF 119.

> 
>  From the abstract in the draft:
> 
> 
> “This document defines a generic, interoperable and scalable 
> architecture to enable transparency across any supply chain with minimum 
> adoption barriers. It provides flexibility, enabling interoperability 
> across different implementations of Transparency Services with various 
> auditing and compliance requirements”
> 
> For me b) does that better than a), especially re the minimum adoption 
> barriers, and the ability to meed ‘various auditing and compliance 
> requirements’
> 
> But is b) consistent with achieving
> 
> “Issuers can register their Signed Statements on any Transparency 
> Service, with the guarantee that all Auditors and Verifiers will be able 
> to verify them.”
> 
> I think that the arch is complete in the sense that profiles are how 
> that is accomplished. But possibly incomplete unless there is a minimal 
> model for auditor verification to compliment the minimal mandatory 
> requirements. I, instinctively, prefer putting it all on profiles. I can 
> imagine various profile qualification and certification programs 
> evolving to suite the various domains.

For the sake of becoming the smallest common denominator, suggestions 
via PR are exactly the thing we can talk about such discussions. As you 
highlighted, I think: there must be a comfortable balance between 
"putting it all on profiles" and "resilient interoperability enabled by 
the core architecture"

> 
> Cheers,
> 
> Robin

Viele Grüße,

Henk

> 
> *From: *Orie Steele <[e-mail]>
> *Date: *Monday, 4 March 2024 at 22:04
> *To: *Robin Bryce <[e-mail]>
> *Cc: *scitt <[e-mail]>
> *Subject: *Re: [SCITT] Should verification keys go onto the transparency log
> 
> Inline:
> 
> On Mon, Mar 4, 2024 at 2:14 PM Robin Bryce <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     *> *Putting the keys somewhere else presumes a retention policy
>     without assuring it.
>     Agreed.
> 
> 
>     > Let's say I don't believe a vendor is honest about their "Registration Policy", and I want to see if they actually authenticated the issuer.
> 
>     Were that the case, I’m not sure I would believe anything I see in
>     the log at face value – be it positive or negative. And I think that
>     is actually a reasonable default position. In which case, the keys
>     being somewhere else is a strength because a second independent
>     source is then what I would want.
> 
> 
> That's a fair comment.
> 
> I think the entire purpose of the "Auditor role" (in the current draft 
> text) is that the auditor does not trust the log operator, and wants to 
> confirm their inclusion proofs are computed consistently.
> 
> In addition to checking the log consistency, the auditor might want to 
> check individual receipts against the log, and verify everything.
> 
> It seems like the draft text has been revised so that the auditor does 
> not verify receipts, and only checks consistenecy.
> 
> 
>     > A policy could be: no authentication, admit everyone (ignoring normative spec text, as implementers frequently do), and if anyone asks to audit, tell them to find the keys themselves...
> 
>     Yes, and adjacent services can, and I expect would, develop to
>     independently solve the problem of key availability for auditing.
> 
>     > SCITT does not need to mandate storing verification keys in the same log as the signed statements, but it is problematic to assert security properties that arise only from having all of:  - payload (software artifact); - signature (cose sign1); - verification  keys (x509 cert or cose key)
> 
>     Yep, I see that. Is it “Auditability” as a whole you think is just
>     impossible to specify without all of those ?
> 
> 
> The latest draft defines the auditor as essentially "a guy who can see 
> the whole log and recompute inclusion proofs".
> 
> The auditor is not a role that has key material, can verify receipts, or 
> confirms if a registration policy was correctly applied.
> 
> If we are good with that definition of auditor, then we are perhaps 
> ready to ship the document.
> 
> 
>     > I feel we need to either move all these in scope, and address them... or move the policy out of scope.
> 
>     I have a fear that moving them into scope will lead to specifying,
>     essentially, that transparency services have some sort of consistent
>     way of logging _/everything/_ they do to verify signed statements.
>     So that auditors can replay and decide if they agree. And as pointed
>     out on the issue, that seems to require a very prescriptive approach
>     and also that a lot of work needs to be done before last call ?
> 
> 
> That's right, to give the auditor an ability to do more, additional 
> requirements would need to be enforced on all transparency services.
> 
> As is, all the auditor can do is collect receipts and confirm merkle 
> proofs (assuming that merkle proofs were used for the receipts).
> 
>     This is a spitball, and not connected to any implementation I had
>     currently imagined:
> 
>     If it is possible in this kind of spec to allow a transparency
>     service to declare, possibly via its registration policies, what it
>     captures and what it expects auditors to have to hand, then adjacent
>     services, or any services, will have a means to index that sort of
>     material in support of auditors. I think the interoperability and
>     auditability then comes from enabling the indexing and collection.
>     This seems like a team sport ?
> 
> 
> Sounds like you are suggesting profiles are required to ensure 
> interoperability.
> 
> That's a valid solution to the problem.
> 
> 
>     And if there is a super clever implementation that can solve it all
>     in one place for a wide range of use cases, so be it. I don’t think
>     that implementation is undermined by drawing the line this way ?
> 
> 
> TBH given that receipts are already divided by which verifiable data 
> structures are supported, I think it's fair to say that SCITT does not 
> work without agreeing to a profile, which at a minimum restricts the 
> verifiable data structures.
> 
> Perhaps that profile is where the Policy constraints belong, and not in 
> the architecture.
> 
>     Cheers,
> 
>     Robin
> 
>     -- 
> 
>     *ORIE STEELE
>     *Chief Technology Officer
>     www.transmute.industries
> 
>     *Error! Filename not specified.* <https://transmute.industries/>
> 
> 
> -- 
> 
> *ORIE STEELE
> *Chief Technology Officer
> www.transmute.industries
> 
> Image removed by sender. <https://transmute.industries/>
> 
>