Subject: [Trans] SCT encoding

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Dec 2014 07:48:27 -0900

One of the open issues (ticket 34:
https://tools.ietf.org/wg/trans/trac/ticket/34)
concerns SCT syntax, with Steve Kent arguing that either ASN.1 should
be used or that there needs to be a clearer justification for the
choice of 5246 representation (see RFC 5246, section 4).  We need to
come to a decision whether or not to go ahead and carry forward what's
in 6962 (the TLS format).  This is a call for discussion - we'd really
like to close this in the next week or so.

Melinda

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Dec 2014 11:50:55 -0500 (EST)

> like to close this in the next week or so.

See also Ben's slide deck from IETF-91 (slide 6 & 7)

http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf

And the raw minutes (look for "slides-91-trans-4.pdf" in the text)

http://www.ietf.org/proceedings/91/minutes/minutes-91-trans

Ben has argued that SCT's appear only as TLS structures or DER format,
and prefers the TLS structure as the DER format is used with OCSP only.

Steve has argued against that since two of the three formats are ASN.1.

At IETF-91, various people mumbled semi-off mic that ASN.1 would not be
their preferred format. So while it seems to be leaning towards using
the TLS structure, it would be good to get some additional voices heard
from the people who were not at the last meeting and from those who only
made comments off-mic to explain themselves a bit better.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Fri, 12 Dec 2014 12:53:11 +0000

> and prefers the TLS structure as the DER format is used with OCSP only.

Actually, also used in certs.

> Steve has argued against that since two of the three formats are ASN.1.

That's not really an argument. My argument is that in ten years' time
almost all CT info will be transmitted as TLS extensions.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Dec 2014 15:53:15 -0500

Ben,

> On 11 December 2014 at 16:50, Paul Wouters<[email-masked]>  wrote:
Yes, but when used in certs (and OCSP responses) the SCT will be in
an ASN.1 encoded context.
> almost all CT info will be transmitted as TLS extensions.
I think mine is a very valid argument based on the fact that 6962-bis
proposed 3 ways to convey the same data and did not explain why we need
all three ways. Your argument above says that CAs will (essentially) cease
logging pre-certs, after having rewritten their code to do so to meet
Google's mandate for EV certs and Chrome acceptance in early 2015. This 
seems
like a questionable projection to me, but maybe there are other details 
that
lead you to this conclusion, but which you have mot shared. Can you 
elaborate
on why you anticipate such a change? (The analysis should be on the 
list, to
facilitate discussion, but it also belongs in the document if the WG elects
to retain the 5246 encoding convention.)

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Dec 2014 15:46:35 +0000

On 12 December 2014 at 20:53, Stephen Kent <[email-masked]> wrote:
> like a questionable projection to me, but maybe there are other details that
> on why you anticipate such a change? (The analysis should be on the list, to

Because of the risk of logs becoming untrusted, SCTs in certificates
may become invalid before the certificate expires, effectively
terminating the cert early.

You can mitigate this to some extent by including many SCTs, but its
clearly better/safer to use SCTs that are retrieved "live" so that you
can always be sure they're valid.

This requires either OCSP stapling or the TLS extension. Using the TLS
extension puts updating the SCTs in the control of the site operator,
which seems like the best way forward.