URL
I noticed the draft was renamed from the name it previously had at the last IETF meeting where it was adopted. The previous name was "JWT and CWT Status List" and the new name is "OAuth Status List". I understand not wanting to have "JWT" and "CWT" in the name, but the new name is somewhat confusing, since it makes it sound like there is a status of OAuth itself somehow. I suggest renaming this to "OAuth Token Status List" to avoid confusion.
See We got feedback from multiple people and hence decided to go for as this seemed a reasonable choice by many. I would not change the title now again before the cutoff, but I'm happy to discuss so in Prague.
FWIW my comments/feedback on and related conversations were only about the document identifier being For the draft title, I'd go with "Token Status List" as suggested URL Note that the document identifier (guess it's called docname in the markdown) needs to start with draft-ietf-oauth- because of IETF convention and the draft being an OAuth WG item. But the document title doesn't have to have "OAuth" in it.
After reviewing the discussion I also would support "Token Status List". And yes, it looks like the discussion in was about the draft URL, not the title.
The name of the issue is "Feedback from call of adoption: Draft title". How should it not be about the title then?
I was commenting on the fact that literally all of the comments only mentioned the draft URL.
I already stated in the ML, but I support `Token Status List"
"Token Status List" seems the most supported option, if there is no objection, we would rename next week. I would suggest removing “OAuth” from the title of the draft and make it “Token Status List”. “OAuth Token Status List” sounds like status list mechanism defined in this draft is only for the tokens used in OAuth/RFC6749, which it is not. Huge +1. Best, Kristina From: OAuth On Behalf Of Michael Jones Sent: Monday, October 23, 2023 10:29 PM To: URL ; Aaron Parecki Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List To Aaron’s naming points, I would be fine changing the title in the draft from “OAuth Status List” to “OAuth Token Status List”, if there’s working group consensus to do so. We could have that discussion in Prague. The name change was motivated by feedback from multiple sources that the old name “JWT and CWT Status List” was too specific in token types, seeming to unnecessarily tie our hands. That said, I don’t think we need to change the draft identifier “draft-ietf-oauth-status-list”. I doubt that there’s another kind of status list happening in the working group that might cause confusion. ;-) Besides, the draft identifier is actually ephemeral. Should the working group draft progress, it will be replaced by an RFC number. Cheers, -- Mike From: OAuth > On Behalf Of Rifaat Shekh-Yusef Sent: Monday, October 23, 2023 7:48 AM To: Aaron Parecki > Cc: oauth > Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List I also noticed you didn't mark it as replacing the individual draft in datatracker. You can email EMAIL and request that they mark it as replacing URL so that the history tracks better. I fixed that. Regards, Rifaat On Mon, Oct 23, 2023 at 10:35 AM Aaron Parecki > wrote: Tobias, Paul, Christian, I just noticed the new working group adopted version of this draft: URL I posted this comment on Github, but I'll repeat it here for others. I find the new name "OAuth Status List" confusing. While I understand wanting to remove "JWT" and "CWT" from the name, I was not aware of that discussion during the call for adoption. I would suggest renaming this to "OAuth Token Status List" instead. I also noticed you didn't mark it as replacing the individual draft in datatracker. You can email EMAIL and request that they mark it as replacing URL so that the history tracks better. I also noticed that there are significant changes to the draft between the individual and working group versions. Typically it is better to post a verbatim copy of the individual draft as the adopted version, and then make changes in a -01 version. Thanks! Aaron On Sat, Oct 14, 2023 at 5:56 AM Rifaat Shekh-Yusef > wrote: All, Based on the feedback to this call for adoption, we declare this document adopted as a WG document. Authors, Please, submit this as a working group document at your earliest convenience. Regards, Rifaat & Hannes On Tue, Oct 3, 2023 at 8:51 PM John Bradley > wrote: +1 for adoption All, This is an official call for adoption for the JWT and CWT Status List draft: URL Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by Oct 13th. Regards, Rifaat & Hannes OAuth mailing list EMAIL URL OAuth mailing list EMAIL URL


and
Payload and Statement seem to be used intermixed in the text. I tried to disambiguate the via "Statement payload". If that does not work, please provide a counter proposal. The term Claim sometimes seem to have meant Signed Statement and sometimes Transparent Statement. Using our interim terminology, that became a selection process for me. Please check, if I made the correct choice in all occurrences (sometimes I had to guess the intent). Consistent Capitalization was a mess. I hope I fixed most of that. Please check. There is still no consistent use of "Registry" vs. "log" vs. "ledger" vs. "Transparency Service", I think. Please check. Please check every use of the term "Evidence" and if an alternative expression could be used. Please check every occurrence of the term "guarantee" or "proof" and if an alternative expression could be used. Privacy Considerations and Security Considerations texts require significant improvement.
Here is my opinion: Registry refers to the facilities used to store and retrieve "Authenticated Statement Data" that has been submitted to a "Transparency Service" "operator". A Registry contains specific "Statements" which the Transparency service supports, as documented in their registration policies document. A Registry may employ different technologies needed to carry out its function to store and retrieve "Statements" that are permitted in the Registry, per the registration policies defined by the Transparency Service operator. The operator of a Transparency Service serves the role of Gatekeeper to ensure the integrity of the Registry data and services provided to access the Registry data. A Statement is contained in a message "Payload" exchanged between a Transparency Service API function and other parties, i.e. consumer inquiries and Notary submissions.
It would help to be able to read the document given the changes proposed here. But due to the make errors documented in I haven't yet succeeded in doing so. Does the build infrastructure automatically build documents for other branches? Or can someone else build and publish the document based on this branch?
Editor's version build via github actions for is located here: https://ietf-wg-URL
LGTM, thanks for finishing this off


A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)


This PR is intended to update URL as the current version has broken codeblock formatting and no longer reflects the current state of the draft URL URL URL URL URL
I looked through the changes and they are fine. Thanks for fixing the over-long lines in the examples.


Good clarification, with a few nits to reduce and clarify the text
All edits have been addressed. I believe this is ready for merging.
Thanks, NAME Sounds like we can address this suggestion separately and we can merge this as-is
For the next submission deadline, RegInfo needs more detail to convey it's purpose. Maybe... it may even need a new name, as RegInfo might not be limited to key/value pairs about registration policy?
LGTMI would prefer "The key/value pair semantics are application-specific, or even possibly specified by each Issuer for each of their Feed." but I am fine with both formulations. Thanks.


PR addressing the conversation around Feed is redundant with Subject, as defined in CWT This PR intentionally contrasts Choice for folks to vote upon: [ ] Rename Feed to Subject [ ] Should we also include CWT_Claims, which contains the subject
Copied over from: URL A feed is a great base for how we can create a series of statements for different artifacts, getting freshness for a receipt/or VEX report. The current definition likely needs to expand a bit to account for: What are the versions of a specific artifact What are all the statements for a version of an artifact What is the latest statement for a specific of a specific versioned : (eg: what's the latest or for the software? If the is a referenced , which stores SBOMs, Scan Reports, how do we drill into each if they all use the same payload of satementByReference?
I'm not sure if "feed" represents the right concept, when it seems to me that the API to the registry will need to offer the ability to query records for specific orgs-products-models-releases, and collect all the relevant records, which likely include a number of ledger entries to various related artifacts. With that said, can imagine also the notion of a different API which would provide a feed of updates to the registry, esp. to allow a mirrored version or to perhaps aggregate from several source registries.
This is a good point and one possible improvement that was already brought up at the previous IETF meeting is to enable some structure in the feed header. For instance, using an array of strings would capture many of the common patterns (such as product > model > release), and allow some advanced functions in the API (such as prefix-based querying). Another approach would be to allow each issuer to structure their feed using arbitrary CBOR representations; while this captures many more complex usages (e.g. packages for different Linux distributions, binaries for different architectures) it becomes harder for the transparency service to understand what constitutes related claims (it requires interpretation of the feed format), and thus, harder to define auditing APIs.
NAME I've got the notes on feeds and I've been working on a proposal. Would you like to collaborate on it? Deferring to 117 for prioritization, but a great discussion as many things will be built upon feeds.
A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM


LGTM, Thanks, NAME the stakeholders to consumers looks like a great change. I don't know if we'd keep both, or replace. I'll merge this to keep moving forward. Also, thanks for the catch on CBOR


This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:


Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.


Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences


simplified a few references & added a WG, some reordering
Thanks, NAME
A small fix and then it will be ready to it.LGTM!LGTM


This PR elaborates on the privacy analysis a bit. Describe why it is important (because we cannot delete items from the log) Remove the BCP 14 keyword (MUST NOT). Both the Privacy and Security Considerations sections should have the character of an analysis. They should be recommendations, or highlight gotchas to implementors. Anything binding should be in the main body of the RFC. Yes, this would need to be fixed in the Security Considerations, too. Expand the "Unless advertised by a Transparency Service" phrase into a paragraph about access control. This way it's more actionable. (Why would you advertise it? When would it be okay to advertise?)
Authors: (NAME NAME NAME NAME NAME I'm inclined to merge this as is. Any disagreements, or additional changes? We can iterate afterward, but seems like a good baseline to add
Yes. this looks pretty stable and uncontroversial. Thanks a ton, NAME


This PR addresses: URL Related issues: URL
Some additional details on the construction and use can be found here: URL I'm not including these in the PR, because I don't understand the security properties required by "SCITT Identifiers", but if the code I wrote covers the security properties, I am happy to do a follow up PR, after this one is merged.
LGTM for the consistency of CBOR structures


This is a simple dependency management PR to decouple SCRAPI from the architecture spec. See SCRAPI can be a layer above, and reference the architecture (dependency) as in HTTP implementation. Decoupling allows us to move forward with the architecture doc, continuing to iterate on SCRAPI independently.


Looking at URL, I think a that some more diverse examples later that show how multiple statements about one Artifact using the same sub Claim can have different semantics than multiple statements about one Artifact using different sub Claims - including illustrating text when one choice can be used an when the other & pros and cons.
Covered above
LGTM


Renamed to: Structure and Content of Signed Statements Updated content based on this thread: URL Added and made both CWT_Claims and mandatory as per the output of discussions added refs and figure label (which are missing all over the place)
LGTM
LGTMLGTM


Explains Feed as the logical collection, with (Subject) as the property to represent the collection.
That seems pretty reasonable to me. Are there any reasons to keep both?
While I'd agree less is more, this keeps coming back when we try to explain it. A feed is a known concept for a collection of related data We're using CWTClaims , which also makes sense to align with existing specs We avoided Artifact ID Attempting to describe a collection of statements as a subject doesn't resonate. We can keep Feed as the concept, and simply say CWTClaims is how you set an identifier for the feed. How does that work?
Then we should deprecate the term feed in discussions, too, and just explain how a subject is used as a subject in this context?
Updated to merge in PR feedback
NAME NAME NAME PTAL as I've made some updates.


!
The diagram reflects my intention.
Here's a slightly modified view to remove the lines behind, add arrows consistenty !


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


A set of consistency fixes for the next draft.
See URL for discussion on the terminology.
The doc uses the three interchangeably Is there a preferred reference to be consistent?
URL is about Media Type. And then references payload and content type. I've been through this confusion before, where Media Type is the definition of a type of identifier. The challenge becomes when using that type of identifier for different parts of a document. When does the media type refer to the envelope itself? When does the media type refer to a property (aka payload)?
I don't understand the question. is of content type and . It is generally a good idea to use a more specific media type. The payload of a cose-sign1 can have a media type, such as or .
It cuts out cruft, so I support this edit, just one minor nit (take or leave it, it's minor to me), before moving onto .


Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this


In case there is no rough consensus to keep federation section, I raised URL to remove it.
I'd suggest we've had a few different conversations about federation of everything in a transparency service, vs. selective promotion of a subset of information across Transparency Services. The later being the ability for a consumer of one or more Transparency Services to promote the content for a subset of their software. Microsoft ships lots of software, However a consumer may only want to promote the Office suite of products into their Transparency Service for internal validation. I'd suggest the wording, as current, isn't well defined and I'd vote to cut this section until more well defined.
If this PR is dropped then we should create an issue to address the underspecification of unpotected headers at registration, especially the idea to preserve unprotected headers. Federation is a simple use case that highlights this problem
Its not simple, and we have seen no implementation support for it to date.
If we are at the point where we need to start from scratch on configuration/registration policy and scrap the initialization section, I personally do not see how we can keep federation and not just remove it (not to drive you and others mad, we can always add back later).I think the new text is too specific. To me (and as in the prior text) Federation refers to having multiple TS, and one TS accepting receipts from another TS at registration time is just an advanced case, for which we don't have clarity yet. As discussed earlier, letting the TS decide what unprotected headers to authenticate in its receipts is a major complication. My preference would be (1) keep a general placeholder on Federation --- better than nothing; or else (2) cut the section. But this leaves many questions unanswered, starting with the two TS in the arch diagram.


and
In section 5.2.3.3 appears out of the blue. It is not clear what a is.
Hi, NAME I'm looking for the reference to 5.2.3.3 in URL and other versions. I don't see where that section exists. Are you referring to a reference where a client is calls the Transparency Service APIs? Or, as there a mention of "client, synonymous with consumer, verifier, etc?
E.g., Is the client the issuer itself? A piece of software that the issuer uses (e.g., a la OAuth2 client)? Does it refer to any role (issuer, verifier, auditor)? IMHO the text should be more specific, e.g., Certificate Transparency RFC explicitly mentions
Thanks, NAME The above text is from Draft 04: I've labeled it for terminology clarification.
In that vein, I would support clarifying it with a "an Issue or Verifier's Transparency Service API client" in the applicable areas of the draft. Would that be more helpful or does it not reduce ambiguity?
Just an update, I plan to send a PR with proposed changes this week.
From the architecture/editors meeting Differentiating: Issuer who signs the statement (The identity of the software component - Wabbit Networks) Client who initiates the registration operation, which encompasses RBAC which is not part of the spec, beyond being authenticated (the build system's identity for access control. The build system has a role to perform operations) - possibly refer to OAuth's definition of client Verifier who evaluates a statement. The verifier cares about the issuer, to know it was signed by a particular issuer. The audit of a supply chain will check the identities involved in the operations.
AJ and I will review this
NAME and I met today to discuss a recap of the authors/editorial meeting (sorry I missed) and how we need to think about 1) a better alternative name and 2) provide a rationale to why we need to have 1, terminology change or not (part of that is the subject of this issue and pending work that should come up in for the latter). For 1, Monty and I are leaning towards agent for now, but we need to brainstorm on adjusted architecture to reflect 2 and "the way" and how it relates to requested edits for the relying party issue in . We will post in progress work and continue to collaborate and sync, updating the WG via mailing list when it is ready for review and feedback across the WG. More to follow.
Thanks, NAME NAME for the focused discussion.
OK, my work on also led me to be confused and think maybe we have meant agent/client when we said verifier. I made some strawman diagrams to discuss this WG members in URL /cc NAME
OK, it seems we are converging in a direction on around verifier and relying party. The diagram based on author feedback demonstrates that with likely updates to the spec forthcoming if that is approved. It turns out, not surprisingly, we need both verifier and relying party. The latter, if tweak terminology, could more clearly refer to client and resolve this issue as well. Given that, and how it relates to here, I would argue that relying party is the correct substitute for client and this could be closed as a duplicate or modified accordingly to address that. This change would be in line with with the RATS specification iff we distinguish between Verifier Owner/Verifier (person entity/logical system for that entity) and Relying Party Owner/Relying Party (person entity/logical system for that entity) and ironically , various OAuth WG drafts (even if it seems not formally defined), and . It was unclear in previous discussion with authors if this is preferable or required, but it nicely aligns with small tactical changes to the diagram in and relevant spec alignment in terminology and explanations.
Still active. NAME do you have time to complete this item?
I had presented on this topic and we had agreed some key revisions had to take place before we could decide to make adjustments. Are we at that point? Additionally, the alignment with RATS and other specs: is this necessary or not? There are some open questions that are not covered, re URL I guess I will take it to the list.
good enough


Retains the concepts and many of the same words as before, but addresses concerns form the mailing list and interim call
I've merged in suggestions. Please re-review, with LGTM or actionable suggestions.
yesLGTM


Upon re-reading the draft to submit an unrelated PR, I noticed there is a missing verb in paragraph about Signed Statements.
LGTM!LGTM Thanks for the polish NAME


While working on a unrelated PR, I noticed that lists that do not have a newline between the list and previous paragraph. The end result is in local testing, and presuming upcoming publication to URL, the lists will not render correctly. I added newlines and also change the equivalent Markdown syntax to match preexisting lists from other sections in the draft that have been around longer. Before: ! After: !
LGTM Thanks, NAME


I found another typo, to make review simple and not mix it in with a more substantive editorial PR that is pending, I am fixing this misspelling in a separate PR for review and likely approval. Correct singed->signed in Section 6.2.2.


Related mailing list thread: URL
these changes make sense to me
As part of , I would like to consider the removal of Consumer and consumer from this specification if we are not going to define it. It is a generalized term and I would rather expend work group time on trying to tailor an appropriate custom definition of it. I will likely post this issue to the mailing list and cross-reference that thread here and leave this issue for review for a week to solicit feedback. Related mailing list thread: URL
I do think Producer and Consumer is a good generic concept, with more clearly defined roles as Relying Party, Verifier, and Auditor, however, I'd support replacing Consumer with Relying Party or Verifier.
But we do not define them nor cite references that do. From a formality and procedures perspective in IETF, is that OK? Thanks for the feedback.
LGTM with some comments to accept/reject Hello, I have been reviewing the specification and there are usages of Consumer(s) as a specific term to be defined in the draft and consume/consumer(s) generically. The use of the term consumer is ill-defined and I would support not consuming time ahead of 119 defining it. Therefore, I am proposing that we remove the capitalized term and some generic usage of it for clarity. I welcome feedback on the pull request to alter or critique specific, individual changes (207), the issue to track the work for more general discussion (206), or in the form of replies in this thread on the mailing list. URL URL If I do not hear back in one week and there is no objection in the pull request, the issue, or mailing list, I will follow up and ask the authors to merge (if it has not been merged already). Thanks in advance for your review and any feedback you provide. Thanks, A.J.


Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.


This is an alternate proposal to to This PR: Keeps Client as : an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization. Replaces Verifier with Relying Party: a relying party depends on Signed or Transparent Statements to verify an Artifact.,
Thanks, NAME Definitely looking for more input, and I’m also ok to close the PRs and issue and use the existing terminology. My main concern is a Relying Party is a consumer of information. They rely on the receipts and signed statements from the Transparency Service. Which makes it a good candidate to replace Verifier If we replace Client with Relying Party, this confuses what we call the entity that registers signed statements. They are not the issuer, as the issuer signs statements, but is not the entity with access rights to the Transparency Service. Both the producer and consumer need access rights. That was what we had as client.
There is still additional work that needs to be done. Client applications submit signed statements, and obtain receipts, so they can include transparent statements in downstream products. A consumer of a downstream product is a relying party, they either verify the transparent statements themselves, or they delegate the verification role to the "verifier" role.
As discussed on today's call. Folks expressed concern that "Verifier" was not friendly enough to "Consumers or Relying Parties", that are supposed to process receipts. Editors Update: We can choose to: [ ] Accept [ ] Accept [ ] Close both PRs and this issue, and keep the doc with Client and Verifier
NAME wanted to take a look for a proposal
Just an update, I plan to send a PR with proposed changes this week. NAME shall we sync up in the comments or out of band elsewhere?
A.J. Yes, let’s get together and work out a proposal. I’m booked today but tomorrow is open except for 07:00-08:00 and 14:00-15:00 PST (10:00-11:00 and 17:00-18:00 EST) Monty
Sorry, NAME I had to dig a bit to find your email in my inbox from the mailing lists but I found it. Invite sent. I think we can make quick progress and draft a PR tomorrow.
Met with NAME and we discussed perspectives and work on this in the near-term, summarized with URL More to follow.
Adding some more notes to plot out the work, Monty and I discussed aligning the diagram with the separate/distinct RATS architecture, but the separate call out of a distinct Relying Party role and how it pertains to agent was discussed when we met, per discussion I missed in today's author/editor meeting. For my future reference, I need to re-review the doc, as well as compare/contrast ,
So I did not make as much tangible progress today and have spent a lot of time thinking and reading as I re-read this SCITT Architecture draft and related WG drafts (RATS, OAuth) where Relying Party is defined. So, before I spend a significant effort in drawing this with aasvg, I would like to quickly highlight the gaps in my understanding via Mermaid so I can quickly iterate. I have tried reading the mailing list but it not 100% clear where the dichotomy between Auditor and Verifier occurred, but they seem overlapping and redundant to me unless Verifier is, in fact, some non-person entity, like the software doing the verification itself (so this goes to what should we rename client to in , separate of this), but does that not in fact mean Auditor is the Relying Party of sorts? It seems Auditor is just giving a specific name to a general kind of consumer and that is not what a Verifier is. So on that note, this is the current version of the SVG diagram in Mermaid ( I hope I got this right, I cannot just have labels like "Issuer" on the left-hand side so I use subgraphs to box those and not do something clever with dotted lines and cause more problems). (Source: URL) It would seem we really need to change the diagram and the terminology to get rid of Auditor altogether, so first, we would move to this. (Source: URL) I was going to do a subsequent edit, but at this point I will have to ask the group: what is a verifier doing that is different from a relying party owner with a relying party? Could you separate one from the other? (Don't you need to replay the log to verify the sequence of statements?) For reference, there is so much overlap with I think we need to either add compare statements to terminology and touch up the current state diagram to disambiguate the use of these terms. Screenshot below. ! So would that mean, if they are in fact separate, Edit 2 incrementing after Edit 1 to reflect my understanding would be ... this? (Source: URL) If we start to think this way, do we consider the software (client/agent/what have you) used by the Issuer to be distinct? Similar but with one of two functionalities (an agent/client/what have you can be for Issuers to get receipts of signed statements or a verifier that reads all of them)? /cc NAME I am not sure this update at the end of the day reflects our discussion, but I feel like I lost the thread of what we discussed and seemed concrete in discussion. Translating it into diagram and wording updates has left me scratching my head.
And just for the sake of dissing RATs... ! IMO this is reversed... to rely on something you must trust a verifier or be a verifier. I think what they mean is for the relying party to depend on a verifier, but what it looks like is that a verifier sits in front of an RP.
A verifier can be a person or automation that was configured by a person. This is likely a great conversation for the NAME would you be able to lead that discussion with NAME
hm... if we are talking RATS an entity can take on both the Roles of Verifier and Relying Party at the same time (rendering the creation and conveyance of Attestation Results moot)
It seems now obsoletes the diagrams in URL and review in a previous meeting reflecting improvements and viable changes based upon answers to the questions posed in strawman diagrams in that comment.
Also of not my updates to the potential (and beneficial) overlap and possible alignment between relying party and client per URL
Ping NAME NAME
I wrote some of my thoughts on URL and aj-stein-nist/ietf-wg-scitt, but for me Client was going to replace Relying Party (Client==RP), so I am not sure if making Verifier==RP is what my intent was when I revived the issue, so I will leave to others to decide.


My take on trying to make registration auditable. This is still very open-ended in terms of implementation choice
I have made optional, but still supported
Steve, Is it too late to add another service API to SCRAPI: Retrieve Registration Policy 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! URL Email: NAME NAME Tel: +1 978-696-1788
Hi, NAME Once the Architecture is settled, we plan to put more focus on SCRAPI, and yes, we can certainly add/edit/remove.
NAME this PR contains guidance for SCRAPI enabling registration policies to be retrieved: URL It also adds optional endpoints for retrieving signature and payloads, not just receipts.
Thanks NAME NAME I'm still not sure how the architecture handles a revoked certificate used to sign the registry log. Would a new log be started with a different signing key and the old log would remain available for reference - with a warning that the signing key has been revoked or is expired? Still trying to figure out implementation details so that REA can support the initiative. I assume the results of a SCRAPI query would contain a warning that the returned results are from a log that has a revoked signing key.
SCITT does not have any messages currently related to revoked certificates. What messages do you propose?
It can be as simple as a warning in response to a query i.e. “Warning: The signing certificate has been revoked or has expired” 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! URL Email: NAME NAME Tel: +1 978-696-1788
Dealing with expired or revoked TS certificates should be straightforward, as you can always obtain a fresh receipt for a previously registered transparent statement. For issuer certificate this is a non-issue as SCITT only guarantees the issuer certificate was valid at registration.
Thanks, Antoine. Is this also the case when the certificate used to maintain log integrity has been revoked or has expired. I’m presuming the registry log integrity is also maintained using a digital certificate – correct? 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! URL Email: NAME NAME Tel: +1 978-696-1788
Yes, that's what I called the "TS certificates", i.e. the certificate used to sign the COSE receipt/countersignature. That's the only certificate relying parties would care about - if there are other internal certificates it's up to the TS implementation to expose the details to auditors through the audit API
Antoine, What is the set of criteria that the TS should use during the registration policy evaluation? 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! URL Email: NAME NAME Tel: +1 978-696-1788 From: Antoine Delignat-Lavaud NAME Sent: Monday, March 4, 2024 8:50 AM To: ietf-wg-scitt/draft-ietf-scitt-architecture NAME Cc: Dick Brooks (REA) NAME Mention NAME Subject: Re: [ietf-wg-scitt/draft-ietf-scitt-architecture] Registration auditability requirements () (PR ) NAME commented on this pull request. In draft-ietf-scitt-URL : -Transparency Services MUST, at a minimum, perform the following checks before registering a Signed Statement: +During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the (34), (33) and (4) protected headers of the Signed Statement as hints. +For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by , to one of the root certificates most recently registered as a trust anchor of the Transparency Service. +The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log. See the updated comment thread on line 403 (now 405) about possible weakening of this requirement — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you were mentioned.Message ID: NAME
Since the refactor and the shift to X.509-based claim signature, the authentication of issuers is no longer auditable - i.e. it is no longer possible for verifiers and auditors to re-validate the claim signature and issuer authentication performed by a TS at registration, which massively increases the trust in the TS (which may now try to register forged claims with plausible deniability - by claiming the TS lost the issuer's certificate used at registration even if none existed). Part of the issue is that claims use x5t instead of x5c. This means there is no mechanism for auditors to obtain the certificate chain used to sign a claim from the TS at registration. Even if x5c was used instead of x5t, only the leaf certificate is required to appear in x5c. Reconstructing the full issuer certificate chain requires at least the TS configuration to link to the configured root CAs used by the TS. Since roots and intermediate certificates expire (or can be updated, as is often the case with PKIX root programs from Mozilla, Google and Microsoft), it is not possible to assume that verifiers can just store the root configuration with the TS's certificate. There are further issues with issuer authentication: >When x5t is present, iss MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. This is not well-specified without a reference to such a regular expression. Is this supposed to mean RFC4514 string representation of a distinguished name? The language of RFC4514 doesn't appear to be regular (it is context free), so this must be clarified. There is also no requirement for the issuer's serialized distinguished name to be produced from the claim's X.509 leaf subject. A malicious issuer can put a different issuer's serialized distinguished name in the iss field and is likely to confuse a verifier who cannot detect the mismatch since issuer authentication is not auditable. This makes iss essentially useless for verifiers, and it may be preferable to set iss to nil if x5t/x5c is used.
I propose we require in the architecture that the full certificate chain used to identify the issuer and verify its signature at the time of registration be authenticated by the TS via the resulting receipt. Given a transparent statement (and possibly auxiliary transparent statement from the TS log recording root and intermediate certificates) verifiers must be able to retrieve and review the full certificate chain. This clearly separates PKI issues (delegated to certificate issuance) and the evidence required to keep them transparent and auditable. The text included a a way to implement this requirement based on transparent configuration statements, which I found useful but may be too detailed/prescriptive for the architecture.
I don't think its in the spirit of COSE to include the full cert chain in a protected header. A thumbprint to a certificate that is in a chain is more concise.
This issue will be closed if no PR is raised by Friday.
Closed with
These changes seem appropriateI suggested a couple of improvements, but overall I support this PR. LGTM


Adjusts text around CDDL and EDN Adjusts text regarding Validation
LGTM, nice and clear changesLGTM


Hi all, This PR comes from a place that agrees: If using an identity scheme, then yes, it must be used in maner consistent with that scheme, But aslo that There is no identity scheme we could all agree on as universally applicable or agreable, further, the space continues to evolve. And, The trustworthiness or otherwise of issuers identity, in the context of a transparency ledger, is temporal and subjective in nature. It's just a question of time frame. This means that regardless of registration time checks, relying parties, auditors and general consumers will have to re evaluate regardless. And will do so according to their own subjective context. Remembering that "It can never be assumed that some Issuers and some Transparency Services will not be corrupt.". And also "A Verifier SHOULD validate a Transparent Statement originating from a given Issuer" ... "and would not depend on any other Issuer or Transparency Services." It does seem obvious that, Syntactic validation of the issuer identity claims makes good sense and supports interoperability. But, Specifying a single identity scheme in the core architecture as "minimally required" does not meaningfully help interoperability when there is no single agreeable scheme, and especially when a TS may be used to underpin identity schemes themselves. Regarding the burden on Relying Parties and Auditors, The definition for "Relying Party" states "a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain". IOW: Relying parties are already expected to deeply consider statements. Assessing the identity asserted by the issuer, at the time the artifact is being considered, seems to be a natural and useful part of that process. Registration Auditability: Requiring that Transparency Services "enough information is made available to Auditors" ... "to authenticate and retrieve the Transparent Statements" is essentially impossible to specify at this level, imposes un-bounded maintenance and storage issues on implementations, and represents a significant layering violation in the architecture.
Editors meeting: will wait 24hours for reviews, with merger if no objections.
Per the editors meeting, I've merged the discussed changes and resolved the discussed topics. I've opened to track the MUST/Should discussion, which wasn't part of this PR. Please review and we'll merge Wednesday morning US Pacific time if there are no objections. I'll incorporate agreed suggestions as well.
Merging with no other feedback.
good enough By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger. Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".


from :
MUST and "enough" does not seem suffiMay be we have to tighten up the you can retrieve the signed statement to something in the future that may only get the hashmore correct than before, still a MUST that is tad bit hard to follow. the change in this scope is okay


This is how a SCITT Signed Statement associates an Issuer making a statement about an Artifact, which has been core to the draft from the start. Previously, these were properties in the protected header, aligned with DIDs: See The use of was to align with other existing standards, for how we associate these concepts. An alternative is to lift these two properties, independently, to the protected header. We already have an in the protected header for additional properties, reducing the duplicity of in the cwtclaims and protected header, potentially simplifing the model. The approach of using cwt claims allows users to benefit from existing cwt libraries, which seemed the better of the choices.
OK so the answer is yes then. I am happy with it, but this is a small, tight PR deleting the editors note, I wanted to understand the implication before I (and maybe others) understand before I approve.
Resolve Section :
LGTM


Clarify the terminology around expiry and refreshing receipts. By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger. Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".


To facilitate this forward for submission on Monday, I'm going to merge a few changes for additional discussion/review.
Fair, could you provide a suggested change? [edit] let me elaborate: not making iat mandatory! But about the fact that extension points in Receipts can render them with an expiration date and that only in the architecture's base definition they do not expire.
After reviewing comments and the paragraph this change sits within, the merged suggestions make a minor improvement, and I don't believe rewinds any problems. While we can/should make additional improvements, can we adopt this change? NAME NAME you have blocking requests. If the merged suggestions don't resolve your concerns, can you either make an additional suggestion or comment on why this shouldn't be merged?
NAME here you go: URL
The changes that have been made to the pull request has lost somethings. The logical receipt itself does not expire. The evidence captured in the ledger is more than just the hash of the signed statement as it has to capture the tests done to the signature and the results. That evidence and where it sits in the ledger establishes a time basis for the decision. A new signature on top of that linkage to the evidence in the ledger is being equated as a whole as the receipt. The "thing" signed is the same (location into the ledger) and the only thing that has changed is possibly the identity key material and algorithm. It is this concept of "never" expiring that is important to key.
from :
Tagging NAME
NAME we'll close this in a week and can reconsider with a PR.
Referring to , the latest changes provide the flexibility for Transparency Services to maintain previous receipts and re-issue them or generate new receipts which may not be persisted. As such, I'm approving this PR as incremental progress.


Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM


Reason: Term was used only twice, not defined, and does not seem to play an important role. !
fiddled with a phrasing nit. This approval is not about the diagram picture, but the content of md that substitutes Identity Documents with URL


changes "document" to "Signed Statement" (was a weird nit close to the suggested change)LGTM


removed "(Artifact)" which seems to have been an artifact....LGTM


I don't understand the motivation behind replacing "any other COSE compatible PKI trust anchor." with "a JSON Web Key Set". Is there an issue with COSE compatible PKI trust anchors that is driving this change?
NAME : What is an example of a "any other COSE compatible PKI trust anchor." besides the JSON Web Key Set?
Good question NAME if JSON Web Key Set is indeed the only possible COSE compatible PKI trust anchor then I see no issues with this change.
I support Steve's suggested change.
I think the point here is to keep it open and not limit to what exists today.
NAME I have not worked on COSE for one minute, but I get the impression that a SCITT Transparency statement could include identities other than X.509, which seems to imply that another form of "trust anchor" is plausible, i.e. a PGP chain of Trust or even a SCITT trusted party - am I mistaken.
These are just examples anyway and as such the list is unbounded. But if you give examples, as you do today, then it better might be good to give examples that are understandable by readers. That is what I have been trying to do. I listed the only COSE example I am aware of.
LGTM to changes


fiddled with the language that intended to be normative and made it normative languageLGTM


This is not correct if we also consider SCRAPI
SCRAPI says Auth is, may or isn’t required on specific endpoints, but doesn’t specify how it’s implemented. Is that inconsistent?
please check my suggested changeLGTMok with changes to 4.3 step 2LGTM


Here is the status: I do not believe there is a security problem. Roy says that Antoine thinks there is a problem. Antoine is, however, not at the meeting.
Antoine can object in the next iteration or during WGLC
The replacement loses the security issue and adds a new one. The modification of removing the certificate chain, which will save space in the ledger, opens up a problem of building the chain dynamically may result in the wrong trust anchor.LGTM


I generalized the description. You need to rotate all keys.
I don't have strong opinions about the MUST vs. SHOULD requirement here. The group will have to sort this out
Was wondering whether the cases where keys are never rotated are actually valid. The implication is the following: if an end-entity certificate has an indefinite lifetime then the certificates of the subordinate and CA certificates also need to have an indefinite lifetime. Is this a realistic deployment? If so, can you describe this deployment?
Sitting in the SUITS meeting, the same question of MUST came up. Someone made the comment that the MIST could be required in the doc, but the doesn’t mean a service that doesn’t follow the MIST guidance, can’t physically operate or even interop with other services. It would mean it’s not conformant to informative guidance, and a security review could seem it not as secure. Which might be fine for a locked down, IoT scenario. After the SUITS discussion, I’m fine with a MUST for operational info, that enables a service to function as they deem fit
Keeping with MUST as it doesn't change the compatibility, and a service that doesn't rotate would still be interoperable, and be operationally not compliant.
LGTM!removed the hyphen from cryptoperiodsApproving the MUST text.


NAME NAME PTAL at the latest if they resolve your requested changes.
Suggest we incorporate Option 1 suggestion from Steve!I see this change as constructive, I asked Steve for clarification on his comments too.Changes as of URL improve the previous text. LGTM


You have to explain what this means and include reference. Since you are likely not going to do this, I suggest to delete this sentence.
I think we should take NAME 's change, and that the current text is problematic.
LGTM


I would not assume certain deployment situations. It is likely that there are many Transparency Services that are not necessarily publically accessible to everyone and the entire architecture would still be totally valid
I agree NAME I know of at least one registry (Transparency Service) that will not be publicly accessible.
NAME always public or not, should we not consider that as material for privacy considerations that follow the line your recommended deletion?Thanks for the updates LGTM


We are inconsistent with our use of "registered" and "recorded" when referring to the addition of signed statements to the append-only log. I recommend using the term "registered" consistently to refer to this act. This implies that some "process" was applied before registration can occur on the append-only log.
Doing a quick search it seems easy and good to make this change, except one place that looks a bit janky. The current document (draft-08 as released) includes a line: It doesn't quite sound technically right to simply replace the word here because the VDS doesn't register things: there are other bits of the higher level TS involved there. Would it satisfy you in this case to change to: I don't want to mess too much with meaningful text changes and it would be a shame to hold up this issue for one detail. And I think this is strictly better because it also suggests that the VDS doesn't record (or validate, or witness, or any other word we might have come up with) Signed Statements that haven't been registered.
No objections here Jon. Thanks for resolving this issue so quickly. Please close this issue after applying appropriate changes.
URL
Closing as resolved by
LGTM


Remove ambiguous details reported in (.
x5t value MAY be included in the unprotected header in support of certain supply chain scenarios.
LGTMLGTM


Address feedback from Hannes in .
Registry, RFC9162_SHA256 is value 1, which supports -1 (inclusion proofs) and -2 (consistency proofs). I believe this registry is defined in another document. The sentence needs to be changed to make the meaning clear.
Breaks circular relationship until one is completed.LGTM


with unclear definition and regex requirements with DN currently in draft.
Calling NAME for some
Perhaps I missed it, but what is the motivation of changing to a URI?
We are specifically customizing the usage of in CWT as defined in . In that document, it is a type and it seems like we shifting away from the base usage of URI to something else and with a regex spec I couldn't find in a relevant I-D, RFC, or standards doc that we can normatively cite as a reference. Is there something I am missing, and is there a valid reference we could use?
I agree the current text is not clear, as it doesn't define or reference any regex. However, stating that the must be a URI with no further specification is equally unsatisfying. How about we drop any mandate to use a particular format of if the protected header is present? The identity of the issuer will be sourced from the X.509 certificate, so the value is largely redundant.
There is a little more detail in the CWT RFC and points to the JWT RFC which in turn points to the string representation of URIs RFC. Are those definitions equally unclear? I don't mind that if others have that feedback I'll close this out and start over. That will obsolete the feedback from Hannes that triggered this PR at the same time. I can bring that on list and reference this discussion.
Ah, yes, I forgot to mention: if we want to retain the use of the string representation of the subject DN of the X.509 certificate for the value, we can reference RFC 4514.
I can also bring that up as an option on list and adjust accordingly if that is ok.
I think it’s unclear, as there is no guidance on the content of the iss, only that it is URI-shaped.
It is similarly unclear to me in the architecture requirements what one should or must do with the DN. It is implied, but left to the implementer to decide for desired X.509 use cases. It is not clear what one should do with it to correctly validate the cert use per the claim, regardless of DN or URI is chosen. Can we both agree that is part of the problem?
In any event, I apologize for the delay, I have created the following thread on list to discuss before moving forward with the PR in any significant way. I may stand corrected and others will prefer your approach (which I dubbed Approach ). URL
Deferring 'till the week of 8/19 as some folks are on vacation.
I support this change on behalf of the URL project.
8192 characters in length that fits the regular expression of a distinguished name. What is the "regular expression of a distinguished name"?
I do understand the intent, but it would seem that distinguished name is not clearly going to have a specific reference we can use. That reference sets aside the regex requirement. I understand the need but there is some assorted LDAP RFCs and other attempts, but none seem to be the right kind of reference, even if about distinguished names in X.509. I am going to propose we go back to what we know and then put forward my understanding and interpretation of the requirement, that we want a StringOrURI like the underlying CWT requires, perhaps with added length requirements?
LGTMLGTM Hello, Last week I attempted to pick up some issues thanks to the many contributions by Hannes Tschofenig. One such issue requesting clarification or change is issue . For that, I made an associated PR, pull request . URL URL So far there has only really been feedback from Corey Bonnell (and that has been most appreciated!). I wanted to poll the list for feedback and understand if there is consensus on using the X.509 Distinguished Name for the issuer of the claim, whether or not there is a clear regex and length requirement. The current text reads like so. characters in length that fits the regular expression of a distinguished name. https://ietf-wg-URL I see a few ways forward. Do nothing, leave the current statement in the specification as-is, and close the issue reported by Hannes as a WONTFIX because it is good enough. Keep the Distinguished Name, and add a useful regex from a relevant LDAP specification proposed by Corey in his comment, RFC4514. Adapt the requirement to match a subset of the underlying data type of the CWT claim iss field, URI (from stringOrUri), and not add an additional requirement for DN regexes and format parsing. Be most permissive and interoperable, remove this requirement entirely. Corey appears to support 2 (please correct me if I am misrepresenting your position, Corey), whereas I prefer 3. I understand the intent of further constraining iss in the presence of X.509 certains and checking against their thumbprint. It makes it more convenient and consistent for the case of Issuers creating Signed Statements with X.509 certificates as a first class solution, but at the expense of the alternatives (short-term and long-term) and resulting interoperability in the long-term. Additionally, the requirement as-is appears to adapt the CWT field to match a differing purpose from its base specification that key use in the context of SCITT. To me, that seems undesirable. Do others have support for one of these positions or related feedback that motivated the current state of the change? Given the feedback over the next week, I will modify or close PR accordingly to meet consensus of authors and WG members who respond on list to the best of my ability. Sincerely, A.J. Stein


Editors call notes: Moving above the diagram is good clarity Changing from defining the roles to the overall diagram caused some confusion. If the PR can maintain the roles, and add diagram clarity, that would be preferred.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained
LGTM


I would argue that in CT Auditors are checking more than Signed Certificate Timestamps
NAME there is a lot of detail there and I am not sure how far you/others want to go, but I decided to keep it simple and I propose adding slightly more detail in URL I am sure you and others will let me know if that is too little (I doubt/hope it is not too much.)
NAME thanks for the issue. Did you have an intent for what to scope? Reading the , it implies a unique focus on x.509, rather than x.509 is one example of identity types that are supported. Considering CT in terms of SCITT: I'd suggest we limit the focus on x.509, and focus on the generalization that an issuer signs the protected header, which includes producing a timestamped signed statement and a timestamped receipt.
LGTM


There is no explanation in draft, GitHub, or mailing lists about resolved key manifest. This change proposes replacement with protected header like other portions of the document.
resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. What does "resolved key manifest" mean?
LGTM


These proposed changes, if accepted,
potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields. I do not understand what you want to say with the second part of the sentence. Even the first part of the sentence do not convey any real meaning.
LGTM of URL


Editors note: updated with a link to the referenced text: 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 , particularly points 2 and 3, so good point.
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"
My read of the Issue and the current state of the document is: This section is under , 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 for a proposal.


Note: This PR assumes is merged, and may need to be updated to fit within the context of 's final text.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained


Closes URL
external attacks and internal misbehavior by some or all of the operators of the Transparency Service. What does the term "each of these functions" refer to?
LGTM to Danny


by allowing the use of a single, protected header parameter instead of a protected and unprotected pair, for reasons described in the issue. This allows implementations to avoid the risk highlighted at the end of , at the expense of a slightly larger protected header. This is not a purely theoretical concern, the most widely used signing service inside Microsoft has implemented this choice, and the separate from Microsoft has too.
The current text mandates the presence of in the protected header when using x509: URL, and allows an unprotected x5chain: URL I propose that the specification allows in the protected header, ideally as a substitute for , but in addition otherwise. The motivation for this change is to add a degree of integrity protection over , and blame for malicious payload otherwise. The current set up does not authenticate or integrity protect the contents of x5chain, only the leaf, which opens up some opportunities for attacks targeting x509 parsers. I can see why this minimal binding can be desirable in some cases (caching large cert chains), but servers that wish to be stricter to reduce their attack surface should be able to.
Thanks for the fix. Seems quite valuable to the overall operation! LGTM!LGTM thanks. For completeness of the record, I was previously against mandatory x5chain and mandatory deep, possibly online checks of the links in the chain. This PR looks eminently sensible for people who want to rely on x5chainDiscussion at the editors meeting to approve. LGTM


This editorial change attempts to per feedback from NAME
The three steps from Section 4.3 on Registration are essentially the same. To verify the signature you have to retrieve the issuer credentials and you have to do item 4. Issuer Verification: The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. Signature verification: The Transparency Service MUST verify the signature of the Signed Statement, as described in [RFC9360], using the signature algorithm and verification key of the Issuer. Signed Statement validation: The Transparency Service MUST check that the Signed Statement includes the required protected headers listed above. The Transparency Service MAY verify the Statement payload format, content and other optional properties.
LGTM for reduction and lack of duplicity


This is a long sentence, maybe break it up into multiple 80 character lines? A policy could be 'unrecognized', 'unparsable', or 'not implemented'. Does 'unknown' imply all of these? Originally posted by NAME in URL


With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1


NAME PTAL
Since the use of COSE is mandatory, shouldn't this be MUST? Originally posted by NAME in URL
It would seem more appropriate to just say , rather than introduce the notion of a "standard COSE implementation". The latter would seem to involve a need to have a certification program for COSE implementations or something unnecessarily involved like that. I don't follow the implications of this. Can it be spelled out some more? I'll also note LGTM!


NAME Incorporated Review Comments!
Thanks NAME lets see if we can agree on append-only log|registry today so we can adapt and merge.
For the sake of clarity, suggesting "append only log"
LGTM


As proposed in at the WG meeting in Tokyo, we would like to move receipts as a generic primitive in COSE. (see issue ) This PR removes all explicit references to the SCITT receipt ID and instead defines Receipts based on . Note that I also incorporated 2 proposed changes to make SCITT statement and receipt signature more symmetrical: Receipts now include the DID of the transparency service. This can be optionally used to discover the receipt signing key. This change was originally proposed at the IETF WG meeting in London. It simplifies statement authorization, as verifiers can only trust the stable DID of the TS instead of worry about keys or certificate that may be rotated Transparency services can now indicate the registration policies that were actually applied. This is very helpful for verifier, for instance to check the freshness of claims. This was proposed in Tokyo
LGTM, see this implementation: URL and demo: URL
NAME can you help resolve the errors?
Hi, Does this change mean that implementations based on native merkle tries (eg will have to translate proofs to this format ? And if that is so, what is the basis for trusting the service that does that ? Or is there scope for registering trie algorithms based on native proofs like ERC 1186 ?
As we're working to complete for 116, I'm assigning to 116
See for a proposed implementation
Closing as has been merged
I'd like to more generally discuss additional information provided by the TS as it issues receipts: Some information "at the root" refers to its signing (timestamp, keying, ID, etc) but implicitly applies to every statement recorded so far. As discussed at the last hackathon, some information "at the leaf" is the outcome of applying the TS registration policy to each signed statement, including e.g. the configuration of the TS at that point (timestamp, authorized keys, DID resolution results, etc) LGTM


NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later


This PR attempts to address the problem of documenting the various ways that known key content types, such as and are discovered from opaque strings or URIs such as and . This PR also explains how DIDs are similar to OIDC.
I have a working demo of this on URL, URL URL Its also possible to do same thing with did methods other than , for example ... There is a demo of that working with index db here: URL This shows that there is interoperability across issuers that use different did methods, that conform to the same resolution and dereferencing interfaces.
made comments, but I think a bit more discussion/work is needed.Asked Kristina to also look at this.a proposal for discussion @ IETF 117 Hackathon and meeting seems very useful to me. :+1: LGTM to merge as a baseline for future discussion


This PR updates SCRAPI to match the latest version of the architecture.
I tried pushing a revision to the datatracker from my fork... but it did not work... so unless this is published by some other author with write access before monday, we will be -00 for a solid IETF with no updates : )
Merging based on requests to meet the draft cut off... assuming CI passes
:ship: itWe should get this up ASAP before the cutoff and prior to hackathon


Issue Also harmonize title with other endpoints
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
On internal or truly public instances this could be MAY


Issue Exposes another issue with signed statement identifiers which is being fixed in a different PR.
LGTM


Issue
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
The optional API endpoints have intent statements that outline the goal of the Endpoints for example 2.2.1 (Issue Signed Statement Endpoint) has this intent statement: Such a statement is currently missing from both: (Transparency Configuration) and 2.1.2 (Signed Statement Registration).
I'll take this one and put a PR up with consistency for all the endpoints
This was fixed in
LGTM


Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM


It's not clear why this would be needed, and it doesn't reflect any patterns in the Architecture. Remove?
NAME there's a reference to "proof of possession", so my guess it that this is meant to enable a flow where the client requests a nonce, includes it in the signed statement (protected header or payload) before signing and submission, to "prove" that they held the key at the time of submission, if it is substantially different from the time of signing. I agree that this should be removed because: It's poorly specified for its stated purpose, without mandatory transport-level security, it's possible to effectively DoS a client by using the nonce they requested quicker than they can. Without authentication, a malicious client can also spam the service for fresh nonce values, causing legitimate ones to fall out of the expiry window before they can be used. There is no mention of a scenario where this is helpful or necessary. If such a scenario emerges, where an issuer signs or has signed indiscriminately in advance, and it is desirable to be stricter about what can be made transparent, there are two easier mechanisms the registration policy can use that don't require an awkward stateful API extension such as this: in the signed statement a counter-signature with a submission control key (which may or may not be the same as one of the issuer keys) Neither requires additional API surface, nor creates additional DoS opportunities. Opened
agree to remove. I believe the intent for including that was the cnf claim in a cwt. But per URL it is for the protocol to define if and how a nonce should be used. Removing this does not preclude the use of cnf. And, at the same time, avoids under (or over) specifying in the wrong place.
Agree I don't believe this endpoint is necessaryLGTM


Hackathon entry for 119, fill in required elements from RFC 3552
I merged the markdown nits, but left the suggestions that should be reviewed by others.
A bunch of Markdown Nits, and some questions on the correlation between Issuer and RBAC, but happy to merge and iterate through additional PRs


Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.


Provides baseline discussion for clarifying . See
Minor nits and there is no paragraph/subsection included in the proposed use case


I believe this is a typo, but perhaps I misunderstood the intended meaning.
Good catch, NAME Thanks for the PR
LGTM


AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?


The working group didn't actually agree on the use of the term "CPE Router", and there were substantive objections to it. I've used the term Home Gateway here, and included a definition that I think includes both ISP-provided routers with integrated uplink support (cable modem or DSL modem) and also includes routers where the WAN link is an ethernet connector. Not clear that this is correct, but hopefully it's evolving in the right direction.


…flag in the Prefix Information Option flags, but in fact Jonathan's document describing the flags field sets it in the Router Advertisement Flags Extension option. We discussed this in 6man and I think the general consensus was to just use one of the remaining reserved bits rather than requiring the additional extension option prematurely, so I'm updating the text to say that, and have asked Jonathan to update the stub router flags document accordingly.


see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.


Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.


I added a section about services provided by the Stub Network. This will need some more work, but it seems useful to have, and it now says that DHCPv6 is generally NOT RECOMMENDED but is permitted, and MUST be off by default.
(Based on recent discussion in v6ops) We don't specify yet the type of hosts on the IPv6 stub network in detail. For example, an IoT device host only needs an address which it can configure with SLAAC based on the /64 on-mesh/on-link prefix. However, there could also be more complex hosts in principle that need their own prefixes (e.g. /64) delegated to it for internal usage and they may like to use their DHCPv6-PD client for that. For example for running multiple virtual machines / dockers inside the host where these VMs are on their own virtual network segment. I expect these cases to be out of scope and there's no requirement on the stub router to do either DHCPv6-PD server or relay role. Do we need to make this explicit in a goal / non-goal / out-of-scope section ?
With my AD hat one, I sincerely hope to keep the stub network with simple devices, else the SNAC WG will try to make a simple problem too complex ;-) Without any hat, I do not mind having an applicability statement with non-goals in it.


Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.


states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. URL
Esko adds: What about the case where DHCPv6-PD is available, but the stub router doesn’t get the desired prefix length or encounters some error in the process? In that exceptional case it still MAY allocate a prefix out of its ULA prefix. Depending on the reader, “is available” and “works for me” can be different things.
My suggestion: Right, MAY would be way too unspecific in that case. MAY basically says "we aren't saying you shouldn't do this, nor that you mustn't do this." :) So I think as you say that what we really need here is to be more specific about exactly what "is available" means. So, perhaps: If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using IPv6 prefix delegation. and Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6-PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix.
Explain what to do if prefix is to narrow, and also if it is too wide. states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. In my defence, I have been left unsupervised.


Actually, the two stub routers might not be connected to the same stub network, and that should be okay. The point is to stabilize the on-link prefix on the AIL if it's provided by a stub router. If stub routers A and B are connected to the same AIL, only one will advertise an on-link prefix. If that one reboots, the other will remember that that prefix is on-link, so it will do the right thing with responses send to hosts on that prefix. The goal is to make sure that the router that rebooted also considers that prefix on-link, even though it's never seen an RA. I think this section needs a bit of work; the clarifications you've requested would be part of that, but it was useful to re-think this based on your comments as well, because I think I see how to make this work in a relatively clean way. If we are not advertising the prefix on the link, because there's a usable prefix on the link, and we get a message from the stub network for an address on the remembered prefix, there are the following possibilities that I can think of: The prefix is a DHCP prefix, meaning it's routable and doesn't belong to the stub router. In this case, the stub router could try to renew it; if that succeeds, it could assume that the prefix is valid on the AIL and forward packets to that prefix to the AIL. If that fails, it assumes the prefix is only reachable through a router, so it forwards the packet using its routing table, and hopes for the best. The prefix is a prefix generated by that stub router. In this case, if the stub router is on a different AIL, it's immaterial, since the prefix isn't routable. So the stub router can assume that that prefix is on-link and forward packets for that prefix to the link; if they reach their intended destination, great. If not, nothing is lost. The prefix is a stub-network-specific prefix. As an example, Thread uses the thread XPANID, which is a 48-bit number unique to a Thread network and its set of credentials, to generate a ULA prefix for the AIL. This means that if there are several stub routers connected to the same AIL and the same Thread network, they will all always advertise the same ULA on the AIL if there's no usable prefix there. This has a really nice benefit of increasing the stability of numbering on the wire in the presence of stub router reboots. This prefix isn't routable, so if the stub router gets connected to a different AIL, there's not much it can do about it. It's not actually clear what to do in this situation, since if there's another stub router still connected to the old AIL, we have ambiguous routing to that prefix on the stub network. In the case of Thread, we don't consider this a serious concern, since thread has similar locality to home networks: if you can't reach the home router, you probably can't reach the thread network you were connected to before either.
Not all aspects described here are fully clear yet, and there's a tension between this text and other PR text that says ULA Site Prefix is used to generate the AIL ULA link prefix. But it's best to merge the new text now and use that as a basis for further review!


The Makefile allows easy building of .txt, .html, or both output files.
NAME Maybe you can merge this PR, or give me write access so I can do it ;-) ?