Subject: [Trans] Update on recently closed trans trac tickets (Jan-March 2015)

From: Eran Messeri <[email-masked]>
Date: Wed, 4 Mar 2015 10:41:27 +0000

Hi all,

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/42>

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 <http://trac.tools.ietf.org/wg/trans/trac/ticket/37>

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 <http://trac.tools.ietf.org/wg/trans/trac/ticket/40>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/13>

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 <http://trac.tools.ietf.org/wg/trans/trac/ticket/17>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/19>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/21>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/22>

Text was added to clarify the motivation for each.

25: Freezing a log's state
<http://trac.tools.ietf.org/wg/trans/trac/ticket/25>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/26>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/27>

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 <http://trac.tools.ietf.org/wg/trans/trac/ticket/28>

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?"
<http://trac.tools.ietf.org/wg/trans/trac/ticket/29>

The section that says this was removed from the draft.

32: algorithm needed for client checks of SCT
<http://trac.tools.ietf.org/wg/trans/trac/ticket/32>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/33>

Added to the list of log metadata.

34: use of RFC 5246 syntax to define the SCT
<http://trac.tools.ietf.org/wg/trans/trac/ticket/34>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/36>

A bunch of error codes were added.

43: key rollover <http://trac.tools.ietf.org/wg/trans/trac/ticket/43>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/45>

The errata was incorporated.

46: Provide explicit instructions for how log servers should handle
already-logged certs <http://trac.tools.ietf.org/wg/trans/trac/ticket/46>

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 <http://trac.tools.ietf.org/wg/trans/trac/ticket/47>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/48>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/49>

Ben believes the current explanation is adequate.

54: Simplify name redaction
<http://trac.tools.ietf.org/wg/trans/trac/ticket/54>

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"
<http://trac.tools.ietf.org/wg/trans/trac/ticket/56>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/59>

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
<http://trac.tools.ietf.org/wg/trans/trac/ticket/35>
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.