On 13/03/15 21:05, Stephen Farrell wrote:
On 13/03/15 20:58, Rob Stradling wrote:
On 13/03/15 20:25, Stephen Farrell wrote:
<snip>
And if we interpret 5280 strictly and conclude that is still a
good plan then the question would be what to do about the SCT
encoding, which could be to do something hacky like prepending
another OCTET STRING tag and a length I suppose,
Stephen, RFC6962 does precisely that, and the current 6962-bis text aims
to do the same.
Really?
Really. That's what all the current implementations of RFC6962 are doing.
I though the extnValue was just the SignedCertificateTimestampList
and did not contain yet another OCTET STRING tag? That how I read
6962 anyway.
Some other folks read it that way too, apparently.
Hence http://trac.tools.ietf.org/wg/trans/trac/ticket/14
S.
Adding yet another OCTET STRING would turn it into an OCTET STRING
inside an OCTET STRING inside an OCTET STRING!
I'd be surprised if Russ or Steve Kent would consider that to be any
better than the current plan (an OCTET STRING inside an OCTET STRING).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
