This repository has been archived by the owner on Nov 10, 2022. It is now read-only.
IEST Last Call: Address Mirja Kühlewind's DISCUSS and COMMENT feedback #316
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addressed by robstradling@3b2ec0a
We'll consider these comments on section 2 at a later date, along with Benjamin Kaduk's DISCUSS/COMMENT feedback on section 2.
Addressed by robstradling@d2d6b0a
The Log ID Registry is merely a source of OIDs that have short DER encodings. A log operator may either (1) request an OID from the Log ID Registry, or (2) allocate an OID themselves (from an OID arc that they control, naturally).
The Registry is not intended to be a global directory of all logs.
"It" (the precertificate or certificate) must have already been logged, because the corresponding SCT (that contains a potentially unrecognized extension) couldn't otherwise exist.
The very next sentence in section 5 already specifies a mechanism for doing just that:
'Note that as per
[RFC7231], in the case of a 503 response the log MAY include a
"Retry-After:" header in order to request a minimum time for the
client to wait before retrying the request.'
I don't think that's a good idea. I can imagine that operational issues might cause a log operator to want to vary this restriction at any time.
Clients should always be prepared to receive get-entries responses that contain fewer entries than they requested.
See also https://trac.ietf.org/trac/trans/ticket/95
It makes sense to synchronize the signature algorithm values we use with the TLS SignatureAlgorithm registry, because our data structures are defined according to the conventions laid out in the TLS RFC.
However, I don't think it's a good idea to use the TLS SignatureAlgorithm registry directly. In 6962-bis, we've taken steps to make log artifacts smaller (compared to RFC6962); related to that, we've removed the option of logs being permitted to use RSA keys/signatures. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 permits RSA, and several other signature algorithms that we don't wish to permit or recommend (i.e. "anonymous", DSA, GOST, and "Reserved for Private Use").
In 6962-bis section 10.4.1, we ask the appointed Expert to "review the public specification to ensure that it is detailed enough to ensure implementation interoperability".
AFAICT from RFC8126, "RFC Required" doesn't imply Expert Review, whereas "Specification Required" does. So I think we should leave it as "Specification Required".
Thanks. In our response to Alissa Cooper's DISCUSS/COMMENTs (see #309), we've already clarified that the Log ID Registry is indeed First Come First Served.
Please don't restart the format wars. ;-)
We must use ASN.1 for all data structures, because X.509 certificates are involved. But we must use "TLS encoding" for all data structures, because TLS is involved. But we must use JSON for all data structures, because JSON is more API-friendly.
It was impossible to please everyone. We had to choose something, so we chose TLS encoding for the data structures, and JSON for the APIs.
As I mentioned earlier, one goal of 6962-bis is to make log artifacts smaller. TLS encoding is more suited to this than JSON.