Ben,
On 11 December 2014 at 16:50, Paul Wouters<[email protected]> wrote:
On Thu, 11 Dec 2014, Melinda Shore wrote:
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.
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.
Actually, also used in certs.
Yes, but when used in certs (and OCSP responses) the SCT will be in
an ASN.1 encoded context.
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.
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
