Below is a summary of the activity on all recently-closed trac tickets.
I hope this summary would help other trans participants catch up and surface potential problems with the proposed resolutions.
We marked those tickets as closed as it was the only way for us to track that we’ve dealt with them - we expect them to be re-opened if there are issues with the proposed resolutions.
As Melinda said, in the future a new status will be used to indicate that a ticket has proposed resolution but needs a review.
42: redacted cert dangers
We’ve added a clarification on what can be considered “overly-redacted” precertificate (since there’s no standard for defining too-broad wildcards in X.509 certificates we could not refer to it). We’ve left out the implications for the client, as it’s up to the client to decide what to do when encountering such a Precertificate (and we do not intend to specify client behaviour, based on previous discussion in the last IETF meeting).
37: client gossping
The ticket correctly made the point that gossip is not well defined enough to make any concrete claims about it. Correspondingly, the BIS text was changed to be less prescriptive about how STHs are exchanged and point to the gossip I-D.
40: Auditor behavior
RFC6962 originally described ‘auditors’, but in a very broad way. We’ve realized that stand-alone auditing isn’t likely to happen (and wasn’t the intention of RFC6962 either), so we’ve clarified what additional auditing responsibilities each type of client can take upon itself.
13: Deal with server farm skew
Added text and an API call to address the problem of a log front-end not knowing about a recent STH another log front-end served.
17: Add advice on CNs
How to redact the CN? Non-contentious suggestion was to allow a single CN that matches the first dNSName entry and use the first entry in the redaction list for both.
19: Rejig API for efficiency/correctness
Originally a client had to make up to three calls to get an inclusion proof (get-sth, get-consistency, get-inclusion-proof). A new API has been added to get all three. This ticket was also partially addressed by the changes relevant to ticket 13 (server farm skew).
21: Clarify signature checking purpose and mechanism
The original goal was to clarify that this is a spam mitigation measure. As Stephen Kent pointed out, the way X.509 certificate validity checks are performed must be accurately specified so logs behave consistently. The BIS was changed to indicate that logs MUST accept certificate chains that are valid according to the X.509 verification rules and may accept ones that have expired, not yet valid, etc.
22: Explain why there are three delivery mechanisms for SCTs
Text was added to clarify the motivation for each.
25: Freezing a log's state
As a part of the metadata description for a log, its final valid STH has been added.
26: Precertificates: Find alternative format to X.509
After a lengthy discussion about the pros and cons of using X.509 for Precertificates, the consensus seemed to be using CMS signed-data objects for Precertificates.
27: Signature & hash alg specification
The original concern was that since RFC6962 defines hash and signature algorithms logs must use, clients must support both. Ben’s justification was that only EC signatures would have been fine but since there are IP concerns, RSA is specified as an alternative.
28: Algorithm agility
Concerned both algorithms used by logs and algorithms used for certificates acceptable by logs. The fix was to point out changing algorithms used by log is unnecessary (would require significant changes to all data structures) and a simple alternative would be to freeze a log and start a new one. As for algorithms used for certificates submitted to logs, the relevant RFCs already specify algorithm agility.
29: "what does ""immediately"" mean?"
The section that says this was removed from the draft.
32: algorithm needed for client checks of SCT
The original ticket was about specifying the details of checks a client should do when verifying SCTs. Ben believes that this has been addressed in the changes made to sections 3 and 5.
33: Cert chain length as log metadata
Added to the list of log metadata.
34: use of RFC 5246 syntax to define the SCT
ASN.1 was suggested as a more appropriate format for defining SCTs as they are served in multiple contexts. Rob and Ben argued that RFC5246 does not forbid the use of TLS encoding and that there are good reasons not to have multiple SCT formats (complexity, extra signing overhead).
36: error indications for log/client exchanges
A bunch of error codes were added.
43: key rollover
Log key roll-over is deemed unfeasible because it would add significant complexity to all data structures involved while a simpler way, of freezing the existing log and starting a new log, exists.
45: Incorporate RFC6962 errata
The errata was incorporated.
46: Provide explicit instructions for how log servers should handle already-logged certs
How should log handle certificates that already have SCTs embedded in them? Text was added to clarify that a log should return a different SCTs for a precertificate and its corresponding final X.509 certificate.
47: Clarify how to deal with (minor) DER violations when manipulating a TBSCertificate
Certificates with DER violations would be hard to manipulate by clients for the purpose of SCT checking. Ben suggested logs should log such certificates and return an error rather than issue an SCT (if they can detect the violations).
48: Enforce the rules for Name-constrained Intermediates
Text was added to indicate that client can verify an SCT corresponds to the certificate it arrived - which is the final certificate or a Precertificate that is appropriately name-constrained.
Not included is what the client should be doing with the result of this check, as we do not specify client behaviour.
49: Explain why OCSP Stapling is acceptable but OCSP Fetching is not
Ben believes the current explanation is adequate.
54: Simplify name redaction
Closed as invalid as we (myself, Ben, Rob) decided not to use Rob’s simplification suggestion (personally I found it introduced different complexities).
56: """*"" domain labels MUST NOT be redacted"
There were no arguments in favour of allowing redaction of “*” domain labels, so the text was changed to reflect that it should not be done.
59: Clarify STH versioning
The STH versioning was rolled-back from V2 to V1 as the only addition, of the CtExtensions field, was not deemed necessary - and could always be added in the future.
35: server SCT transmission restriction is misstated
Small clarification that servers may send SCTs to clients if they are embedded in the certificate or in the stapled OCSP response, even if the client did not indicate it can receive SCTs in the TLS handshake.