trans issue tracker | 27 Mar 17:08 2015

[trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate

#79: Precertificate signature must be over something other than just the

 If I understand the CMS spec correctly, then we're currently defining a
 Precertificate to be a CMS structure that contains a TBSCertificate and a
 signature over just that TBSCertificate.
 That means that the components of a Precertificate can be trivially
 rearranged into an X.509 certificate with a valid signature!

 To fix this, we need to either...

 1. Require the SignedData.encapContentInfo.eContent field to contain
 "something || TBSCertificate" or "TBSCertificate || something".
 2. Require a signed attribute to be present in
 SignedData.signerInfos[0].signedAttrs.  This is essentially equivalent to
 "TBSCertificate || something" in terms of what gets signed.

 I think 2 is the cleaner solution, unless there's a cryptographic reason
 to prefer "something || TBSCertificate" (e.g. to protect against chosen
 prefix collisions?)


 Reporter:                           |      Owner:  draft-ietf-trans-
  rob.stradling <at>           |  rfc6962-bis <at>
     Type:  defect                   |     Status:  new
 Priority:  blocker                  |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
(Continue reading)

Eran Messeri | 27 Mar 13:45 2015

AIA/cRL for logged certificates

I'd like to get opinions from the list on solutions to the following problem, which Ben originally pointed out. It applies to Precertificates currently, but would apply to X.509 certificates if ticket #4 is accepted.

An "undesirable" certificate is issued and logged (without including Authority Information Access / CRL distribution point) and upon discovery is revoked - the CRL distribution point in the issuer or one of the intermediate certs will list it as revoked.
That certificate would be signed a second time with the same issuer key, but not logged a second time (as the SCT produced for the first certificate is valid for the second one). When it is served, it is served together with a chain that is different than the one logged, and the issuer or intermediates in this chain point to a different AIA/CRL that does *not* show list this certificate as revoked (The implied assumption is that the attacker controls the private key of the issuer).

Implication: A client believes it has a legitimate certificate by validating the SCT and performing an online revocation check.

Potential mitigations:
- Require that the client only use the AIA/CRL distribution point from the chain logged in the CT log (which forces the client to fetch it online, before completing the connection).
- Require the presence of AIA/CRL distribution point in the end-entity certificate.

Any other suggestions?
Trans mailing list
Trans <at>
trans issue tracker | 27 Mar 12:34 2015

Re: [trans] #4 (rfc6962-bis): Should we sign TBS for Certificates?

#4: Should we sign TBS for Certificates?

Comment (by rob.stradling <at>

 Eran, don't the existing PrecertChainEntryV2/X509ChainEntry structs
 already hold the original submission?

 Can't we resolve this ticket just by changing
 !SignedCertificateTimestamp.signed_entry and
 !TimestampedEntry.signed_entry from...
                select(entry_type) {
                    case x509_entry: ASN.1Cert;
                    case precert_entry_V2: TBSCertificate;
                } signed_entry;
                select(entry_type) {
                    case x509_entry: TBSCertificate;
                    case precert_entry_V2: TBSCertificate;
                } signed_entry;

 I think it makes sense to retain a different struct for each
 !LogEntryType, rather than try to unify them.  New !LogEntryType values
 might be defined in future that aren't unifiable with the existing two.


 Reporter:  eranm <at>  |       Owner:  benl <at>
     Type:  defect            |      Status:  new
 Priority:  major             |   Milestone:
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |

Ticket URL: <>
trans <>
trans issue tracker | 27 Mar 11:34 2015

Re: [trans] #4 (rfc6962-bis): Should we sign TBS for Certificates?

#4: Should we sign TBS for Certificates?

Comment (by eranm <at>

 There seems to be a consensus among the authors that this is a good idea.
 As Emilia Kasper put it:
 "I can see only strong benefits in this: 1) unifying the handling of
 precertificates and certificates and 2) avoiding all sorts of library
 slack and brokenness in handling the unsigned component of the
 That implies that the signature in the SCT will not cover the signature in
 the X.509 certificate itself, so it would validate for different
 certificates that are the same TBSCertificate, signed with the same key
 multiple times (potentially yielding different signatures).
 To allow auditing of the original submission, I propose adding a field to
 the PrecertChainEntryV2/X509ChainEntry struct (which will be unified) to
 include the original submission.


 Reporter:  eranm <at>  |       Owner:  benl <at>
     Type:  defect            |      Status:  new
 Priority:  major             |   Milestone:
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |

Ticket URL: <>
trans <>
Watson Ladd | 26 Mar 15:56 2015

draft-linus-trans-gossip-ct-01 doesn't work

Dear all,

Suppose I can consistently redirect a client C to a masquerading
server M. The proposed gossip mechanism will not detect this, as SCTs
are only ever sent back to the server they are received from. This
should be fixed by having clients gossip constantly about STHs, thus
ensuring that if any honest server is contacted, the MITM is detected.

Watson Ladd
Tom Ritter | 25 Mar 15:10 2015

Re: draft-linus-trans-gossip-ct-01: gossiping STHs

On 24 March 2015 at 16:48, Ben Laurie <benl <at>> wrote:
> If TLS clients and servers send each other STHs, then realistically, there
> is no privacy issue: everyone has all STHs.

I had thought about this for a while, I'm going to outline my train of
thought as briefly as I can, but it'll still be a tad long.

How do I (TLS Client) get STH's? Few ideas:

- Request them from logs from a given SCT (and logs learn my browsing
habits, that's bad)
- Request the latest SCT-head from logs (less privacy-worrying, but
still - I don't like the idea of my browser calling out to random
third parties so they can attempt to track me and learn my online
- My browser proxies latest SCT-head in update checks??
- Servers send me STH's (and Inclusion proofs?) with an SCT
- Servers proxy STH (and inclusion proof) requests for a client

Proxying is not a fully deployable mechanism. Not all server operators
are willing to allow outbound connections from servers, you have to be
whitelist log addresses to avoid becoming a full proxy. Even if I did
get STH's this way there is still a problem. So I'm ruling that out.

A STH is minorly useful, in that it's a signed statement we may catch
a log having lied about.  But without an inclusion proof for a SCT, a
STH is just a dead piece of data the client holds and then gives to
someone in the hope it's useful later. Assume a client gets an
inclusion proof along with an STH. This is one more component of the
lie, but still, is just dead data that does not significantly help the

Are STH's (by themselves) even useful for detecting misissuance? No.
If we assume a log will misbehave we have to assume a log will try to
cover up it's misbehavior. This means an SCT will have a valid STH
associated, and that a log will be willing to continue a 'fork'
(including all other SCTs, so differing in only a single node)
essentially forever in the hope of not getting caught.  So assume the
STH 'branch' extends from the point of misissuance until present day.
So we need consistency proofs.

An STH (even on the misissuance branch) is not useful without linking
that STH to another STH. There is value in linking STHs with
consistency proofs - if one cannot get a consistency proof between two
STH's _then_ you've detected log misbehavior. But how does someone get
consistency proofs? They can only come from the log. So either the
client attempts to resolve consistency proofs itself (this brings us
back to the original problem of asking a log or proxies, so we rule
this out) or the client passes on STH's for someone else to resolve
consistency proofs.

Of note: if I've been attacked, and have a STH on a misissuance branch
I will _never_ just 'happen' to get a consistency proof that shows
it's an attack. I'll always have an STH hanging out I can't connect,
but also can't be certain _isn't_ connected. I can _only_ detect
misissuance by _actively_ querying a log for a consistency proof
between by misissuance STH and a valid STH.

Another issue with STH's is (at present) they can be uniquely
identifiable. A log can (as I read 6962) create a new STH for every
SCT they create. This is unrealistic, and it's not the bedrock of my
argument, but it's worth noting. Regardless of that loophole, a STH is
somewhat identifiable (and potentially a tracking mechanism) depending
on the algorithm they are given. Design me an algorithm, and you can
find some amount of privacy leak in it. (For example, a SCT can reveal
last online time. Or, in conjunction with other STH's, it can reveal
some indication of what sites you visited.)

Another independent component: I assume a client does _not_ have a
trusted auditor, because said auditor is basically some third party
you're going to send your SCT (aka browsing history) to. And who is
doing to run the default auditors? Privacy problem, the same as OCSP
lookups. (nb. a client can obviously opt-in to a trust auditor)  In
some cases I note "something can only come from a log" but it could
probably some from an auditor. But the problem is the same: who is
this auditor/log we're willing to release data to by default?

Gossiping STHs seems natural, but I could not arrive at a way to
connect all the data in a privacy preserving manner.  If we follow
strict privacy protection this is what I arrived at:
A) Clients get STH's (from servers I must conclude) but don't care
about them. (Or they get STH's + Inclusion Proofs and validate the
B) Clients pass the STH back to someone (which must be the server it
got it from.  (Or a opt-in trusted auditor))
C) An auditor collects the STHs from somewhere (must be servers
following from (B)) and retrieves consistency proofs between them.

Misissuance is detected at (C). Because the client itself does not do
anything with a STH, and because a SCT will always resolve to an STH,
it seemed like it would be both simpler and bandwidth reduction to
just cut it out.

Ben Laurie | 24 Mar 22:48 2015

draft-linus-trans-gossip-ct-01: gossiping STHs

It seems to me that the I-D is missing a trick: everyone should gossip STHs. They are the bedrock on which CT is founded.

If TLS clients and servers send each other STHs, then realistically, there is no privacy issue: everyone has all STHs.

If you don't maximally gossip STHs you make forks easier.

Trans mailing list
Trans <at>
Melinda Shore | 23 Mar 20:22 2015

Poll for adoption of working group draft on threat analysis for CT

Hi, all:

This is a call for adoption of a working group deliverable
providing a threat analysis for CT, based on the summary
provided by
and on previous discussion on this mailing list.

This call closes on Friday, April 10.  Please review the
slides and provide an indication of whether or not you
support draft adoption.


Melinda & Paul
Salz, Rich | 23 Mar 20:06 2015

IETF 92 Meeting minutes

IETF attendees, please post corrections.




One milestone, we’re late; IETF tradition.

Using issue tracker.

Anyone implementation updates?  Nordunet and akamai still active


Ben and Eran hampered by lack of audio


RFC 6962-bit update


Threat Analysis (Steve Kent)

                Threat is a motivated capable adversary; threat analysis (see RFC 4949), taxonomy of actors and classes

                Threat analysis requires that security functionality or goals be clearly articulated

                Most don’t need this, just Security Considerations, since they’re not security protocols

                CT is a complex security system with many elements and thus seems to merit a threat analysis

                Why? Can help guide system designers; after design, helps users understand what it provides

                Current text

                                Mis-issuance is either syntax (bad profile) or semantic (to a wrong entity)

                                Malicious CA vs not-malicious; errors vs attacks; logged vs not logged; benign vs conspiring logs

                                Detailed outline of attacks

                Missing in current text

                                List of adversaries?

                                Concise statement of security goals, such as “the goal of CT is to deter, detect, and help mitigate certificate mis-issuance”

                Part of 6962-bis or separate doc? (No strong pref, but perhaps bis is long enough already)  If separate, perhaps rename to include “logs” in name since it doesn’t talk about client behavior  

                Consensus to adopt as a WG document; will go to mailing list for confirmation


Gossip (dkg)

                Gossip keeps logs accountable (e.g., meet MMD, not present spli view of tree head)

                Monitors are auditors, not all auditors are monitors

                Biggest issue is privacy considerations; relationship between clients and servers, but not between auditors/log and server/log – speak up if you disagree

                Gossip happens among various parties (see preso)

                Recommend mix in “noise” in auditor response to avoid disclosing browser history

                Terminology confusion: TLS client vs log client, e.g.

                Some updates to the (nice) multi-party pictures and flows offered

                Not enough people read it; premature to talk about adoption, but it got well-received in the room will raise on mailing list.


Open issues in trac (eran)

                #4 sign TBS for certs?  Consistent with precertificates, avoid bad encoding of sig params.  Good idea, yes.

                #10 – blinked and missed this, sorry

                #41 – handled by steven kent

                #53 – requiring logs to order entries; no, clarify it’s not a requirement

                #55 – security considerations, no since going to define client behavior

                #58 – limit STH’s per unit time; hard to enforce

                Client behavior – 20 tickets, slot on agenda

                #8 client privacy; significant change, but not be enough; postponed


Any interest in a document describing client behavior?  No enthusiasm; to be on list


RFC 6962-bis update

                Handled server time skew

                Added machine-readable error codes to responses (e.g., malformed request, invalid cert, etc)

                New API merges Get STH, get Consistency:Proof, get InclusionProof

                Added metadata for log parameters (including final STH for frozen logs); comment if anything missing

                Algorithm agility: propose to freeze log, start new one; if necessary, will have to include all old data in the new log.

                See Steve Kent’s open issue, which pointed to an RFC for some ideas and more details; agree need more details on what clients should do when this happens








Senior Architect, Akamai Technologies

IM: rsalz <at> Twitter: RichSalz


Trans mailing list
Trans <at>
Benjamin Kaduk | 23 Mar 04:38 2015

comments on draft-ietf-trans-rfc6962-bis-07

[Why yes, I did have a printout of trans documents to read on the plane.]

In section 2.1, hash function agility has not quite been inserted, since
"[t]he output is a single 32-byte Merkle Tree Hash."

In section 3.4.1, "TLS clients that support the extension SHOULD send a
ClientHello extension with the appropriate type", is "the appropriate
type" ever anything other than "signed_certificate_timestamp"?  If not,
maybe it's best to just spell it out.

The specific contents of the "timestamp" field are only written out in its
description in section 3.3, but not in any subsequent descriptions
(whether TLS data structures or JSON).  Perhaps there should be a small
section at the beginning noting that CT represents times as milliseconds
since the epoch, ignoring leap seconds, to clarify for all occurrences.

In section 4, maybe the extra fields SHOULD be ignored?  This seems
relevant for interoperability...

At the bottom of page 19, should "synchronization" be written out in full?

In section 4, describing the "error_code" field, only one generic code is
given, but the running text is written as if multiple were provided.
Here, and elsewhere, there seems to be inconsistency about whether a colon
is used after the hang text for the itemized list.

In section 4.1, my comment about the base64-encoded 'extensions' data from
the binary codes document also seems applicable here.

At the bottom of page 21, the paragraph about avoiding forcing v1 clients
to upgrade is a little confusing to me.  Perhaps this scenario could be
spelled out in more detail to reduce the potential for confusion.

In the subsections of section 4, I don't know whether we feel a need to
specify that arrays of things are JSON arrays (as opposed to some other
sort of array; I'm not really sure what this misreading would look like).
I guess it's probably fine to leave it alone.

In 4.3, I think the document's convention should have
us explicitly say that the tree_head_signature element is base64 encoded.

In 4.4, the "Note that no signature is required on this data" seems to
only apply to the 'consistency' output, and not the others (since a
signature is supplied for them).  Probably best to just avoid the pronoun
entirely.  Also, the description for 'consistency' should be more clear
about the order in which the base64 encoding and array creation is
performed, just to be sure.

The document seems to play a bit fast and loose with claiming that (leaf?)
hashes and STHs can be "before" and "after" each other (sometimes written
as "<" or ">").  We can compare both the timestamps or the tree size from
which a STH is generated, and I think we should be clear about when which
(or both!) checks are performed, throughout the document.

-Ben (the other one)
Benjamin Kaduk | 23 Mar 04:04 2015

comments on draft-zhang-trans-ct-binary-codes-01

Please specify what data description and interchange formats are being
used.  E.g., sections 4.1 and 4.2 are presumably using TLS syntax, and
section 5.1 should specify that both input and output are JSON structures.

In section 5.1, in the description of the 'extensions' field, we see that
"Logs should set this to the empty string.  Clients should decode the
base64-encoded data and include it in the SCT".  Should these be RFC 2119
"SHOULD"s?  Also, what "the base64-encoded data" is could probably be more
clear, i.e., saying something about if the server sets extensions to
something other than the empty string, it MUST be base64-encoded data, and
if the client receives something which is non-empty, then it does the
decoding and includes it in the CtExtensions portion of the
SignedCertificateTimestamp.  (Hmm, I don't see it explicitly mentioned
that that's what SCT means, either.)