jiebi/CodeConvo huggingface dataset:
Code change:
component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. <del> Component identifiers are serialized using the production grammar defined by STRUCTURED-FIELDS.  The component identifier has a </del> <ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a </ins> component name, which is a String Item value serialized using the "sf-string" ABNF rule.  The component identifier MAY also include defined parameters which are serialized using the "parameters" ABNF

Related discussion:
text: is too restrictive, we'll have to somehow relax the requirement on the serializer (for instance, by stating that the serializer needs to implement 8941 or a successor RFC - that is an RFC that obsoletes 8941). FWIW, I agree that this would be good. But it is not what the spec says.
No, we reference the current document and if that document is updated or obsoleted by something else after publication then you as an implementer go and follow that. That's how updating RFC's already work. All the specs and systems that implemented RFC2616 didn't suddenly break and become invalid when 7230 or later 9110 came out. Here, It's up to the updaters of 8941 to make sure there's A serialization section. Your view of specification dependency is not at all in line with reality.
I see where you're coming from; I'd appreciate if you would do the effort to understand where I'm coming from. The difference here is that any spec that extends 8941 with new types by definition is not backwards compatible. This is because 8941 has no extension points, has drastic error handling and thus requires a wholesale spec update for new things. This is very different from most other RFCs that we're using here. If there is agreement about what we want, why don't we just say it?
To illustrate further: RFC8941-vs-8941bis is like XML1.0-vs-1.1 or HTTP1.1-vs-2.0, not like RFC2616-vs-RFC9112.
That's a very specific definition of 'not backwards compatible' and one that I suspect many would be surprised by. Just because there are no explicitly nominated extension points doesn't mean you can't evolve the specification in a backwards-compatible fashion; the key requirement is that valid inputs per the 'old' version are also valid inputs per the 'new' revision. That is the case for sf-bis. It is true that an invalid input for RFC 8941 will now become valid; specifically, a type value beginning with 'NAME used to generate an error, and now will not (provided that the following characters are appropriate). The reasonable question to ask at this point is whether it's realistic / probable that an application will be depending upon that error being thrown to operate.
Code change:
component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. <del> Component identifiers are serialized using the production grammar defined by STRUCTURED-FIELDS.  The component identifier has a </del> <ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a </ins> component name, which is a String Item value serialized using the "sf-string" ABNF rule.  The component identifier MAY also include defined parameters which are serialized using the "parameters" ABNF

Related discussion:
text: Can you suggest when that might be the case? Because I find it doubtful in the extreme that this will cause real-world problems.
I agree that this wouldn't cause real-world problems. I just also wish that our specs actually say what we think should happen, instead of requiring people to figure out. So in this case, I think we can solve this by saying "RFC 8941 or a revision obsoleting it".
Since NAME acknowledges that this doesnt affect interoperability and this is merely a "wish", NAME why don't you go ahead and incorporate your proposal so we can ship this spec?
NAME - please don't claim what I said something I did not say. My position remains: the spec should be clear about what it expects implementers to do. Right now it is not. If the agreement is "use RFC 8941 or a future revision", why don't we say that?
Proposed change: URL
Code change:
by the Transparency Service MUST be checked. In essence, when using X.509 Signed Statements, the Transparency <del> Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by "x5t" located in the protected header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service.  An "x5chain" with a leaf certificate that corresponds to the "x5t" value MAY be included in the unprotected header. </del> <ins> Service MUST build and validate a complete certification path from an Issuer's certificate to one of the root certificates most recently registered as a trust anchor by the Transparency Service. The protected header of the COSE_Sign1 Envelope MUST include either the Issuer's certificate as "x5t" or the chain including the Issuer's certificate as "x5chain".  If "x5t" is included in the protected header, an "x5chain" with a leaf certificate corresponding to the "x5t" value MAY be included in the unprotected header. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of

Related discussion:
text: 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
Code change:
alg (label: 1): REQUIRED.  Signature algorithm identifier.  Value type: int / tstr. <del> tree_alg (label: TBD): REQUIRED.  Merkle tree algorithm identifier.  Value type: int / tstr. </del> <ins> verifiable_data_structure (label: TBD): REQUIRED.  Merkle tree algorithm identifier.  Value type: int / tstr. </ins> crit (label: 2): REQUIRED.  Criticality marker.  Value type: [ +label ] <del> The criticality header MUST contain the tree_alg label. </del> <ins> The criticality header MUST contain the verifiable_data_structure label. </ins> The envelope payload MUST be computed by the process defined for the <del> tree_alg. </del> <ins> verifiable_data_structure. </ins> The envelope payload MUST be detached, and recomputed by the verifier.

Related discussion:
text: This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.
Code change:
alg (label: 1): REQUIRED.  Signature algorithm identifier.  Value type: int / tstr. <del> tree_alg (label: TBD): REQUIRED.  Merkle tree algorithm identifier.  Value type: int / tstr. </del> <ins> verifiable_data_structure (label: TBD): REQUIRED.  Merkle tree algorithm identifier.  Value type: int / tstr. </ins> crit (label: 2): REQUIRED.  Criticality marker.  Value type: [ +label ] <del> The criticality header MUST contain the tree_alg label. </del> <ins> The criticality header MUST contain the verifiable_data_structure label. </ins> The envelope payload MUST be computed by the process defined for the <del> tree_alg. </del> <ins> verifiable_data_structure. </ins> The envelope payload MUST be detached, and recomputed by the verifier.

Related discussion:
text: There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.
Code change:
3.5. <del> Floats are integers with a fractional part, that can be stored as IEEE 754 double precision numbers (binary64) (IEEE754). </del> <ins> Floats are decimal numbers with an integer and a fractional part. The fractional part has at most six digits of precision. Additionally, like integers, it can have no more than fifteen digits in total, which in some cases further constrains its precision. </ins> The ABNF for floats in textual HTTP headers is:

Related discussion:
text: Is this PR meant to include ?
Yeah, oops. Need more coffee.
Try now.
Otherwise, looks alright to me.
The current definition of sh-float is surprisingly hard to serialize correctly, the best C-code I could come up with is: int serializeshfloat(char buf[18], double d) { int p = 0, l, dig; buf[0] = ''; buf[1] = '\0'; if (isnan(d)) return (-1); if (fabs(d) >= 99999999999999.95) return (-1); if (d = 99999999999999.95) return (-1); if (d < 0) { buf[p++] = '-'; d = -d; } p += snprintf(buf + p, 18 - p, "%-16f", d); while (buf[p-1] == ' ') p -= 1; buf[p] = '\0'; return (p); }
+1 from me, our primary focus should be on data types that will have good interop. That level of precision isn't necessary for any current use of HTTP headers I'm aware of, off the top of my head.
Proposal: Call these decimal. Allow a maximum of 9 digits on the left of the decimal place and 6 after. This matches the definition for int and allows storing this in the same sized slot with a or conversion factor.
ABNF gets much simpler.
NAME That would probably curtail the range too much. I think it is desirable to be able to move posix time_t timestamps in these.
If this really is an integer with fixed point semantics, why do we need it at all?
Because it's easier than making people specify "divide the number by a million to get its real value"? That said, I agree that 9 digits to the left of the point is probably not enough, so a floating point representation is more useful. This is the ABNF equivalent of NAME C code, yeah?: That easily gets us a current 32-bit time_t plus microseconds, and a whole range of other values besides.
Why do the arguments about size of integers not also apply here? is 64-bit on my system, which doesn't fit in the sh-integer definition either.
The current time is ish. You don't need to prefix it with 30 bits worth of zeroes.
Code change:
3.5. <del> Floats are integers with a fractional part, that can be stored as IEEE 754 double precision numbers (binary64) (IEEE754). </del> <ins> Floats are decimal numbers with an integer and a fractional part. The fractional part has at most six digits of precision. Additionally, like integers, it can have no more than fifteen digits in total, which in some cases further constrains its precision. </ins> The ABNF for floats in textual HTTP headers is:

Related discussion:
text: I've read the IETF105 minutes, and thought about the fixed-point discussion. All the uses for "decimal number with fractional part" I can think of\ would reasonably served by at least 10 digits to the left\ and at least 3 to the right of the point. So I would support any fixed- or floating-point representation that supports that range of values. \ that's all that matters, right? \ a ten-decimal-digit time_t gives us until November 20, 2286
Using the max-six-decimal definition, and allowing 15 digits with no period or decimals, this C-code will do the job: static char * sh_float(double d) { static char buf[40]; int n; if (fabs(d) < 1000000000) { n = snprintf(buf, sizeof(buf), "%f", d); while (buf[--n] == '0') buf[n] = '\0'; if (buf[n] == '.') buf[n] = '\0'; } else { n = snprintf(buf, sizeof(buf), "%.15g", d); } return (buf); }
Sorry, wrong button.
If I take , then I can almost represent that in a JS float in the most horrific way imaginable: But that doesn't quite fit. 69999999999999999 doesn't fit into a double. If you want to remember the number of additional decimal places so that you don't lose any precision on those trailing decimal places (things like 0.3 are surprisingly tricky to re-encode), you are left with supplementary values. Can someone make a better case for any more than 10^10 values here? I couldn't see a good one. You can fit a 32-bit value in that. If you really think that time_t is valuable, which I'm totally not convinced of, then fewer steps might be acceptable. I can pack this:
PR updated. Any further comments, or ready to merge?
Code change:
Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent <del> Statements registered by each Issuer.  However, the Registrations of </del> <ins> Statements registered by each Issuer.  However, the Registrations on </ins> separate Transparency Services are generally disjoint, though it is <del> possible to take a Transparent Statement from one Transparency Service and register it again on another (if its policy allows), so the authorization of the Issuer and of the Transparency Service by the Verifier of the Receipt are generally independent. </del> <ins> possible to take a Transparent Statement, a Signed Statement with a Receipt from the first Transparency Service in its unprotected header, and register it on another Transparency Service, where the second receipt will be over the first Receipt in the unprotected header. </ins> Reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements.

Related discussion:
text: 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
Code change:
9. <del> This document establishes a entry for the HTTP/2 Settings Registry </del> <ins> This document establishes an entry for the HTTP/2 Settings Registry </ins> that was established by Section 11.3 of RFC7540. <del> Name: ENABLE_CONNECT_PROTOCOL </del> <ins> Name: SETTINGS_ENABLE_CONNECT_PROTOCOL </ins> Code: 0x8

Related discussion:
text: Add SETTINGS prefix to parameter name ENABLECONNECT_PROTOCOL. Fix one typo ("s/a entry/an entry/"). Remove "(type = 0x8)" which is ambigous (what is type?) and redundant with code listed in IANA Considerations section.
thanks
Code change:
2.3. <ins> When a HTTP client makes a request for a resource for which it has an appropriate dictionary and the dictionary was stored with a server- provided "id" in the Use-As-Dictionary response then the client MUST echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". For example: 2.4. </ins> When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header.

Related discussion:
text: This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!
Code change:
once in the signature input.  Parameterized keys MAY appear in any order. <ins> If a dictionary key is named as a covered component but it does not occur in the dictionary, this MUST cause an error in the signature input string generation. </ins> Following are non-normative examples of canonicalized values for Dictionary Structured Field Members given the following example header field, whose value is known to be a Dictionary:

Related discussion:
text: Includes several document cleanups for signatures, to publish as -09
Also: If there is no query string should the corresponding signing text be or ie. should the query value be empty or just consist of one Should we return with this request and return on this request This is what I opted for in my implementation. See shows that http4s makes the distinction between blank queries and empty queries is simpler I think this is a corner case that is worth explicating very clearly, perhaps even with a test.
There are quite a few occurrences of the header in the draft. From an implementation point of view, Go "swallows" the header and it is not part of the standard Request structure. There's a good reason for the Go library to do it, and in fact the draft recommends to use NAME instead. Can we remove from examples, e.g. Sec. 2.1, so we don't train people to do the wrong thing?
There are only a couple instances of the "host" header in the current draft left, and one of them (section 2.1) is specifically about how to format headers. It could be removed from the other example signature input strings without affecting anything negatively. Same with the "date" header, which could be confused with the "created" parameter, see
This sentence is correct: But it's true for most reasonable uses of , and people will still be using this parameter. So why not add:
No, we explicitly did not want to conflate this with the jwa registry. We also didn't want to have a second tier choice like having "alg=jose" and then having the actual algorithm elsewhere, since a big problem with late editions of the Cavage draft were exactly that process. (See the mess around "hs2019"). The editors discussed this at length and decided the best compromise was to define a way that jwa algorithms could be used in an interoperable fashion, but not to allow runtime signaling with them. Better to have the choice of jwa be signaled within the application level. Additionally, it's preferable to not use the runtime parameter to signal the algorithm any way, which is discussed at length in the security considerations.
All good, so why aren't you using normative language?
It's not normative because this section defines the algorithms, not the parameter.