Fabrice | 30 Aug 22:48 2014



Regarding the transport of SCTs as part of OCSP responses, the RFCs only talk about it in the context of OCSP
stapling. Can SCTs also be provided in non stapled OCSP responses to TLS clients?

Also, should 6962-bis also reference rfc6961 (multiple OCSP responses extension) in addition to rfc 6066?

Or should the language be generalized to just talk about SCTs in OCSP responses, no matter how those
responses are provided to the TLS client?


-- Fabrice
Fabrice Gautier | 28 Aug 18:13 2014

Clarification regarding SCTs and intermediates.

Hi all,

Per my reading of rfc 6962, it seems that SCT (in that RFC) are only
produced for Leaf certificates. 6962-bis introduce a possibility that
intermediates certs are also logged and SCT produced for them.
(Section 3.2.3. Using a Name-Constrained Intermediate CA)

This raised a couple questions:

- How are SCTs for intermediates provided to TLS clients ? Can they be
provided through the TLS extension? Through the OCSP response?
Embedded in the leaf cert ? Or only embedded in the intermediate cert

- If intermediates SCTs can be provided by the same channel as SCTs
for leaf certs, how is the TLS client supposed to know which cert
correspond to a given SCT? Should the TLS client just try all the
certs in the chain until the signature match ? - afaict, there is no
data in the SCT that bind it to the cert, beside the signature.

- If I, a TLS client, have SCTs for both leafs and certs, assuming I
figure out which one is for which, what kind of policies are we
expecting the TLS client to apply. I realize this is probably out of
scope for the RFC, but I'm curious what the expectation are here.

In both 6962, and 6962-bis, the TLS client behavior is very shortly
described in section 5.2. TLS Clients. It basically boils down to one
sentence "they (TLS clients) should validate the SCT by computing the
signature input from the SCT data as well as the certificate and
verifying the signature,"
(Continue reading)

Paul Wouters | 28 Aug 17:16 2014

end to end email encryption using CT gossip protocol

---------- Forwarded message ----------
Date: Thu, 28 Aug 2014 11:15:38
From: Paul Wouters <paul <at> nohats.ca>
To: Trans <trans-bounces <at> ietf.org>
Subject: end to end email encryption using CT gossip protocol



 	For End-To-End, our current approach to key distribution, is to use a
 	model similar to Certificate Transparency, and use the email messages
 	themselves as a gossip protocol, which allow the users themselves to
 	keep the centralized authorities honest. This approach allows users to
 	not have to know about keys, but at the same time, be able to make sure
 	that the servers involved aren't doing anything malicious behind the
 	users' back.

 	To allow the system to be easily distributed (across multiple identity
 	providers), key servers can authenticate the user via existing 
 	identity protocols (with OpenID Connect for example). The model of a 
 	server with a transparency backend is based on the premise that a user
 	is willing to trust the security of a centralized service, as long as 
 	is subject to public scrutiny, and that can be easily discovered if 
 	compromised (so it is still possible to compromise the user's account,
(Continue reading)

Melinda Shore | 21 Aug 00:09 2014

Gossip protocol text

Hi, all:

One of the issues that came up during the meeting in Toronto is how
to handle the specification of a gossip protocol.  Ben has a proposal
included in the current draft.  But, the sense of the room during the
session was that this should probably be split off into a separate
document, a gossip protocol specifically for CT, intended to be
published as a working group product and as an experimental protocol.

So, we're checking to see if there's mailing list agreement that
this is how we'd like to handle specification of a gossip protocol.
(At this time I'm less concerned about whether or not this would be
an experimental RFC than I am about whether or not there's agreement
to split this out).

In terms of whether or not we'd have someone to take on producing
the document, Linus Nordberg has volunteered, so we do have
someone to take responsibility if there's agreement.

Melinda Shore | 6 Aug 21:57 2014

Minutes uploaded

I've uploaded an initial draft of meeting minutes from IETF 90
to: http://www.ietf.org/proceedings/90/minutes/minutes-90-trans

Many thanks to Karen O'Donoghue for taking excellent meeting minutes.

Rick Andrews | 5 Aug 23:10 2014

Clarification needed

In thinking about how log servers should behave, I came up with two cases that should probably be addressed in the –bis so that all log servers behave the same way.
1) Let’s say I’ve issued a cert and embedded the SCTs in the cert. Now I (or someone else) send the cert to log servers using the add-chain command. What happens? Should the log server see if one of the SCTs is from itself, and if so just return that SCT? Or should it generate a new SCT?
Rob Stradling helped me understand that the SCTs in the cert would have a "entry_type" of "precert_entry", so the log server shouldn’t just return that. Instead, it seems that it should create a new SCT with an "entry_type" of "x509_entry". But it’s worth clarifying that this new SCT would contain a hash over the entire cert, including the existing SCTs, even if one of those embedded SCTs originated from that same log server.
2) Finally, is it worth clarifying that while anyone can invoke the add-chain command, only CAs are expected to invoke the add-pre-chain command? Should log servers return an error if the pre-cert presented in the add-pre-chain command does not contain the poison extension?
Finally, it might be worth clarifying Section 4.2, Add PreCertChain to Log, where the input is described as “An array of base64-encoded Precertificates”, which seems to imply that the CA can send multiple pre-certs and chains in a single command. The rest of the description makes it clear that the log server expects only one chain, the first cert in the chain is the pre-cert and the following certs are the (non-pre-cert) certs in the chain.
It’s not clear to me if I should create issues in the tracker for these. I thought I would get some initial feedback first.
Trans mailing list
Trans <at> ietf.org
Stephen Kent | 31 Jul 00:21 2014


I created a set of tickets, based on a small subset of the comments I 
in messages I sent before the Toronto meeting.

Melinda Shore | 30 Jul 23:13 2014

Tracking implementations

During the session last week I was a bit surprised by the number of
people saying that they were doing implementations, and I think it
might be useful to get a better handle on that.  If nothing else, it
helps quite a bit during the publication process if it's known
that there are interoperable implementations and that we know a little
bit about them.

So, I'd be grateful if people who've are working on implementations
and who can discuss them publicly could speak up, let us know the
status and whether or not you'll be releasing source, and provide a
pointer to a repo or other documentation if you're able.  Also let
me know whether or not you'd be willing to have your implementation
mentioned on a wiki page listing implementations.

Thanks again,

Melinda Shore | 30 Jul 19:32 2014

Follow-up from Toronto

Hi, all:

Many thanks for a productive meeting last Friday.  We'll be getting
minutes posted ASAP, but in the meantime the audio recording of the
meeting has been posted here:
We'll also get the link to the Meetecho recording sent out once
it's posted (Friday sessions are not up yet).

Over the next few days we'll be bringing follow-up questions from
the session to the mailing list.  We're also interested in getting
high-level feedback about the two new logging proposals, but the
focus will remain on making progress on the -bis document.

Thanks again,

Melinda & Paul
Richard Barnes | 25 Jul 17:59 2014

DANE transparency

I didn't get my thoughts put together in time to get to the mic in the meeting today, but here's roughly what I was going to say:

tl;dr: Spam on CT logs is the only major problem to solve here, and protocol is probably not the way to solve it.

Doing transparency for the whole of DNSSEC is an unsolvable problem.  It's massive, like Wes pointed out, and littered with tautological pitfalls.  I could imagine some form of "DNSSEC pinning" allowing subordinates to impose hysteresis on frequently-accessed domains, but going further than that quickly approaches the madness that Stéphane noted.

Instead of focusing on the internals of DNSSEC, we should focus on the things that actually impact protocol, i.e., the TLSA records at the leaf.  Normal CT is totally sufficient for these -- certs/pubkeys asserted in TLSA are still certs/pubkeys.  If we need to change the syntax to capture things slightly differently, we should do that, but it seems straightforward.

The only reason that chains are needed in CT is to defend against spam.  With DANE, the potential spammer is the authority, so he can make as many spam domains as he wants.  So the "DNSSEC chain" is useless for spam mitigation.  It's all so possible that DANE-asserted certs will change more often, so again, we might want to tweak what's logged (e.g., to log the public key).  Fairly minor change.

We're left with the question of how to prevent spam.  I'm not sure there's a protocol mechanism here.  It seems like you could have a local policy at the log to, say, limit the rate of updates that are accepted.

So I think we should:
1. Forget about solving DNSSEC transparency generally
2. Focus on getting CT ready for DANE
3. Identify any tweaks that are necessary to support DANE-asserted certs
4. Maybe write some guidelines for anti-spam


Trans mailing list
Trans <at> ietf.org
Eran Messeri | 23 Jul 22:30 2014

When are non-EE certificates expected to be logged?

Following a discussion about correlating SCTs to certificates (ticket 23):

My understanding is that any intermediate CA certificate may be logged (either as a Precertificate or after issuance) *in addition* to the end-entity certificate.

RFC6962 only requires TLS clients to validate SCTs for server certificates (presumably end-entity certificates), so SCTs for any intermediate is not very useful.

The only case I see where an intermediate CA certificate is logged *instead* of a CA certificate is when a Name-Constrained intermediate CA cert is logged.

In light of this, it seems that ticket 23 can be solved by specifying that TLS clients check all non-embedded SCTs against the end-entity certificate or the intermediate certificate with extension OID

Trans mailing list
Trans <at> ietf.org