Clarify MUST/SHOULD within the Registration Policy

[SteveLasker]

Transparency Services SHOULD ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration.

If not, I expect a cross-linked PR to explicate all the registration policy specification that was removed in the past (for lack of alignment and ambiguity and generalities) and explicate it all. The WG considered this not ideal in previous editorial review, so I assume this alternative approach is unlikely. So I would change it to SHOULD.

_Originally posted by @aj-stein-nist in https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/231#discussion_r1567490916_

[ad-l]

@aj-stein-nist we discussed this in the editor meeting. The current requirement on auditability of registration is a compromise between introducing explicit mechanisms (such as explicit claims for registration policies and trust anchors) and being so under-specified that the architecture doesn't meet any security guarantee for verifiers.

The fragile consensus we have reached is that auditability of registration is required but how it is achieved it entirely implementation specific. If we relax this MUST into a SHOULD, then we are expected to explain under which circumstances it is acceptable for an implementation to ignore this requirement.

I would prefer if we could give suggestions instead on how implementations are expected to meet this requirement. For instance, we could say that implementations may register their policies as claims and record certificate chains in the x5chain header, but make it a recommendation that allows implementers to do something else

[aj-stein-nist]

I can commiserate with your point in generality, but you cannot practically have a MUST requirement you don't define if you want this go to RFC. I do not think it will not get only my attention; it will definitely hold up review from ADs and others (I'd expect).

MUST with no detail is not implementable. I think I have repeated this a few times but I will reiterate in writing quite bluntly because it seems the problem here is being missed.

As an alternative, I'd recommend we say 1) edit the draft in near term to say SHOULD in the interim (until long-term steps that follow at step 4); 2) scope work for a registration policy profile mechanism in charter or other WG review; 3) build a notional minimally viable registration policy profile that is agreeable to standardization and be demonstrable; and 4) after step 3 has sufficiently advanced in long term agreement and meaningful consensus, then adjust the SHOULD back to MUST long-term and require registration after 1-3 are completed. Again this final edit will be contingent on this group is comfortable with the first or first N profiles. I don't see any other way.

Let me know what you think. The current status quo, to me, reflects a "let perfect be the enemy of good" philosophy with an odd compromise in a detail we can't define yet, but I would like to know if other authors and the larger WG members agree.

[robinbryce]

@aj-stein-nist do you mean this draft can make RFC status with a SHOULD, but that it specifically notes a future move to MUST based on a seperate initiative to hammer out this point ?

3) build a notional minimally viable registration policy profile that is agreeable to standardization and be demonstrable; and

The implication is that it would stay a SHOULD until, and unless, that happens. Personally, I think that approach decouples the question of "what is good" for registration policies in a useful way. But maybe that is not what you meant ?

Essentially, I just don't personally believe we know enough about "auditability" in general to make good choices right now.

[aj-stein-nist]

@aj-stein-nist do you mean this draft can make RFC status with a SHOULD, but that it specifically notes a future move to MUST based on a seperate initiative to hammer out this point ?

Correct. When I say profile, I mean creating a separate draft with a profile, one way to specifically demonstrate a registration policy, others could use to follow that SHOULD in the architecture. One profile could be made, if others have differing views two or more could be made. But only after at least one profile made and evaluated could the architecture have an update to change SHOULD to MUST.

[robinbryce]

This sounds very practical to me. Thanks!

[rjb4standards]

IMO, the Transparency Service registration policy MUST state the type of payloads that are acceptable along with specific requirements and/or constraints. Here is an example of a policy where anything goes:

"This Transparency Service Registry will accept any type of payload with no specific requirements or constraints."

Policy Requirements/Constraints SHOULD specify maximum payload size, acceptable payload content types (mime type), acceptable payload content materials i.e. SBOMs,

[aj-stein-nist]

IMO, the Transparency Service registration policy MUST state the type of payloads that are acceptable along with specific requirements and/or constraints. Here is an example of a policy where anything goes:

As this pertains to my position on this issue, we cannot agree to the type of payloads or their type. Even "a policy anything goes" side steps the type. I stand by recommendation in https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/236#issuecomment-2098721464. If we only say you must have a policy where, at a minimum, anything goes, that is what we encourage. Implementers will implement only that. That is what we shall get.

@rjb4standards, do you have an anything goes registration policy in practice or something else?

[rjb4standards]

Email MIME payloads are a good example of anything goes.

[aj-stein-nist]

Email MIME payloads are a good example of anything goes.

Thanks for that example. MIME payloads are informative. Let's consider the different MIME transfer encodings, we have plain text, 7-bit, 8-bit, binary, quoted, and base64. Of those there can be a variety of payloads in a payload with their own type.

Anything goes: let's say we use text/plain per one of several layered RFCs per the IANA media type registry is completely free form. That is a media type with guidelines, but I can write anything in there at all. How will it help Verifier and Auditor tools in architecture understand the policy programmatically? How will clients know how to facilitate Issuers' making Signed Statements?

You could say it'll just be plain text, but you will still need to explain the structure. Same with JSON (just that, very loose structure) and CWT (more structured with caveats), but you need definitions of anything goes.

I would say anything goes for programmatic usage of a TS is interesting to me but others have explained in the mailing list and other venues that is impractical or undesired. So how would this be used in practice? A key design principle, given authentication requirements prohibiting anonymous Statement creation and issuance in the draft, contradict, even if not practical. Am I misunderstanding a key design decision?

[rjb4standards]

AJ, consider a scenario where an entity is providing "evidence locker" services, which can be presented in court. The party operating the evidence locker service doesn't need to know what the evidence payload contains, or what format is is provided in, but they must be able to produce and present the original evidence data, whatever it may be. REA does this today in order to satisfy US SEC regulations to prove that cybersecurity controls are in place and functioning regularly within a company, just in case the data needs to be presented in court.. This is all part of our "Trust Registry" offering called SAG-CTR.

[aj-stein-nist]

I think your replies convey part of my confusion. Your description describes an application that "wraps" or contains a SCITT Transparency Service (you talk about SAG-CTR and Trust Registry Concept). That may be an interesting application, but it extends the core requirements and architecture philosophy of a SCITT Transparency service. It is an application with a TS store, not a pure TS. Is that correct? It seems we are confusing both of these concepts, perhaps you can clarify if I am understanding correctly.

To that point, let me say I want to build a pluggable TS client, perhaps to perform an Auditor role. I want to be able to read the TS inside your SAG-CTR app via API conforming to WG specs (we will presume you offer this feature to clients, it's already been decided for this hypothetical scenario). Via the API, I find one or more registered Transparent Statements and there are server records that indicate two different registry policies over the course of time, how would I interact with your SAG-CTR Trust Registry) in a conformant way with draft standard in this I-D? It would be exceedingly difficult, or perhaps not possible, without writing custom code to understand each successive change in the free-form text registration policy? Should I just email you or your support engineer to know how I interpret words or phrases in that free-form text registration policy when it is ambiguous and I need to write code for that?

I ask because it seems for your application, built on top of spec-conformant TS, why have a registration policy at all? Again, I am talking about programmatic access for client operations to register the payload. I know talking about the content of any other payload itself is different, and I completely understand the context you presented here for your application layer.

[rjb4standards]

Fair question AJ.

The SAG-CTR Trust Registry provides client with two main services:

1. Evidence locker (anything goes), but it currently only works with SAG-PM evidence data today, but can support any type of evidence artifacts
2. Registry of Trust Scores where software consumers can check the trust score for a specific product; this requires a well known payload. Trusted parties upload SAG-PM evidence data containing a SAGScore and other information, which the Gatekeep examines before registering a product in the "Trust Registry", kind of like a Registry of Deeds. I demonstrated this risk sharing info service to NASA and the DOE as a means to share risk assessment scores related to the CISA Secure Attestation Form collection and risk assessment processing that begins in June.

[aj-stein-nist]

OK, so re scenario 2, since that application layers on top of the SCITT Architecture more closely than one, how would we account for this scenario, what would I or others do?

Via the API, I find one or more registered Transparent Statements and there are server records that indicate two different registry policies over the course of time, how would I interact with your SAG-CTR Trust Registry) in a conformant way with draft standard in this I-D?

[rjb4standards]

AJ, IMO, the SCITT architecture can easily support both use cases presented.

We demonstrated how SCITT can be used for discovery of key artifacts during the 117 Hackathon using an FDA use case, including Trust Scores stored in a SCITT Trust Registry. A VRF was uploaded into the Trust Registry, which contains links to all required artifacts to perform a risk assessment. A software vendor simply provides a link to the VRF in the Trust Registry, just how Jon and I demonstrated this use case during the Hackathon .

REA will identify the SAG-CTR Trust Registry with two SCITT registration policies - one for evidence data preservation and the other to post trust scores. IMO, SCITT supports both of these use case scenarios.

[aj-stein-nist]

AJ, IMO, the SCITT architecture can easily support both use cases presented.

I would disagree that it should long-term, even if it can today (and largely to make the draft convenient for review in my opinion). I think we are getting caught in the weeds regarding two use cases for a specific application that layer on top of a notional SCITT Transparency Service, but we are not addressing the key concern in this GitHub issue with ones of those two use cases through the question I asked. I will come back to that. To reiterate: it is not effective to support a mandatory MUST requirement on a registration policy that is, essentially, not a policy with any consistency or reason that we understand as human operators, but not computers (e.g. anything goes). If we want that, change the qualifier to SHOULD, at least for now, as we are requiring something we cannot define beyond "well I have something, it can be whatever." That does not befit a RFC. Long term, it appears we are building a system for programmatic access and automation with no ability to bootstrap clients to read or write to the Ledger.

We demonstrated how SCITT can be used for discovery of key artifacts during the 117 Hackathon using an FDA use case,

Rest assured, I was in attendance at 117 during the Hackathon and I have not forgotten your demonstration of a use case, but the architecture I-D has changed over time (as we approach 120) and the lack of consensus and changes around the registration policy was one of the key issues at 117 and subsequent IETF meetings up until now. I hope others will chime in.

REA will identify the SAG-CTR Trust Registry with two SCITT registration policies - one for evidence data preservation and the other to post trust scores. IMO, SCITT supports both of these use case scenarios.

So regarding use case 1, what would the actual registration policy in plain text contain verbatim? I am going to copy-paste the current edtior draft's section on registration policy. If anything goes is the default, can it be a text/plain document with no content to imply that? Would it say NO or no or NONE or None? Even this baseline I can think of a few ways to encode it, all less than ideal if not "empty" content in an media type, and that is only those that I can think of. We MUST have something (as it stands, I oppose that for being logically inconsistent) but cannot even agree on that without some amount of discussion. So this further motivates my belief that we need profiling.

4.1.1. Registration Policies

Registration Policies refer to additional checks over and above the Mandatory Registration Checks that are performed before a Signed Statement is accepted to be registered to the Append-only Log.

Transparency Services MUST maintain Registration Policies.

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. For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor.

Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by registering them as Signed Statements on the Append-only Log, and distributing the associated Receipts.

This specification leaves implementation, encoding and documentation of Registration Policies and trust anchors to the operator of the Transparency Service.

Again, registration policy at this time is not actionable. I appreciate the context from your product solutions on top of a possibly conformant TS, but it further supports my impression that we cannot.

[rjb4standards]

REA supports the current Registration Policy language contained in section 4.1.1 and encourages others to support this description of the Registration Policy, which empowers the TS operator to decide what type of payloads they will register.

REA's SCITT Trust Registry implementation, SAG-CTR, will be fully compliant with the SCITT protocol, when the SCITT specifications are compete and approved using the IETF consensus process. REA is a fully committed supporter of SCITT, from the beginning, and will remain so as radical transparency practices continue to be adopted and a trust anchor capability evolves. In the mean time, REA will continue to operate and improve its SAG-CTR Trust Registry conceptual implementation of SCITT to provide the radical transparency consumers need in the software supply chain. Hoping to see everyone at the CISA ICT_SCRM Task Force conference on June 12 where C-SCRM implementation topics will be discussed: https://www.cisa.gov/news-events/events/innovations-ict-supply-chain-risk-management-conference

[aj-stein-nist]

REA supports the current Registration Policy language contained in section 4.1.1 and encourages others to support this description of the Registration Policy, which empowers the TS operator to decide what type of payloads they will register.

This is a GitHub issue regarding a concern and an interest in changing it. It seems we are talking in circles, I will interpret your feedback to me you are in favor of SHOULD. As it stands, your current position on the I-D and your implementation conflict with the very intent of the MUST in question in the issue.

Hoping to see everyone at the CISA ICT_SCRM Task Force conference on June 12 where C-SCRM implementation topics will be discussed: https://www.cisa.gov/news-events/events/innovations-ict-supply-chain-risk-management-conference

I do not see how that is immediately relevant to the IETF specification in general or this issue in particular, but I will be in attendance. I was under the impression the mechanics of a SCITT Transparency Service implementation are far in the weeds, but if not, that is exciting and I look forward even more to attendance.

[rjb4standards]

See you on June 12.

I will reiterate my position on this matter: "REA supports the current Registration Policy language contained in section 4.1.1 and encourages others to support this description of the Registration Policy, which empowers the TS operator to decide what type of payloads they will register."

[SteveLasker]

There's a lot of great discussion here for various points:

• Some Transparency Services will operate with generic use cases. The Evidence Locker is an interesting one where there's effectively no content type filtering. Generic for content type, but specific to a legal arena, for a set of constrained users that would have Access Rights to the instance. The discussions on registration policies have been more specific to the indentity (issuer), but it's a good example of open types.
• Many Transparency Services will be alongside other storage solutions (SCITT.io scenarios) as SCITT is not a storage service, rather a means to record Who said What about an Artifact, recorded at a specific time. The "What" could be an SBOM about a binary.
• What the doc does focus on is the issuer validation, to assure the issuer is a valid identity, in a valid format. For instance, some Transparency Services may only accept issuers from 1 or a few roots. It's not scoped to support rando identities, or even very valid identities that don't pertain to it's scenario. Imagine a Content Authenticity service that records C2PA metadata. Maybe it doesn't support code-signing certs, and requires other EKUs.

Back to the registration policies and policy language. There are no clear winners for policy languages, even for specific domains. What the spec says is a Transparency Service must provide the details of the registration policy. It should be in the docs, and we might even add a discovery API to SCRAPI. By allowing different Transparency Services to support different registration policy languages, we allow the ecosystems to grow, and adopt ones that become a well-known for that industry or horizontal.

Consider different CA's that have different policies for what types of entities they'll issue keys. You may trust some more than others, because of their strict policies. For instance, 3 years of business records, while others may accept anything that's sent to them. Buying tickets through TicketMaster has more trust than buying tickets on craigslist. Both are valid, and both have enough info to trust them for what they are.

[SteveLasker]

Editors call notes:

1. There are two categories of auditors. One for verifying an individual registration, to walk what registration policy was applied.
2. Auditors for verifying the consistency of the log.

We refer to MUST, relating to the registration policy, but we no longer have a property reflecting the registration policy that refers to another signed/registered statement.

Action points:

• [ ] Clarify different auditors
• [ ] Reconcile a registration policy must be verifiable by an auditor, but haven't defined where to find the registration policy.