On 10/03/14 19:25, Phillip Hallam-Baker wrote:
I am currently working on entering RFC6962 into my protocol compiler.
This has 'certain ideas' about regularity and conformance which is of
course the point of the exercise.
Some issues arising:
[Page 17]
extensions: An opaque type for future expansion. It is likely
that not all participants will need to understand data in this
field. Logs should set this to the empty string. Clients
should decode the base64-encoded data and include it in the
SCT.
I have no idea why this would be needed. JSON allows any object to be
extended with arbitrary additional tags. I have no idea how this would
be used as well. There isn't a mechanism to tell the receiver what type
of data to expect.
Phill,
Page 17 says:
"Clients should decode the base64-encoded data and include it in the SCT."
JSON is used for the Client<->Server request and response. The SCT
format uses "TLS encoding", _not_ JSON. Pages 12 and 13 define the SCT
v1 format.
"extensions" from the JSON response needs to be encoded by the Client as
the "CtExtensions extensions;" field in the "struct {...}
SignedCertificateTimestamp;"
As for why "extensions" would be needed...
Here's where the idea of having "extensions" first came up:
https://groups.google.com/forum/#!topic/certificate-transparency/Dbs9y1SVPgU/overview
In the "Question about PRIVATE option" thread today, I noted that we
might need an SCT extension to explicitly carry the "entry_type".
It's all about future-proofing. If we want to add features to SCTs in a
backwards-compatible manner, we'll define "extensions". If we want to
add features to SCTs in a backwards-incompatible manner, we'll change
the SCT version number.
If we did need to extend a message the way to do it would be to extend
the object with a new tag. JSON rules require the tag be ignored.
There is an open question on how to manage JSON extensibility. Some folk
are proposing going the XML route and an equivalent of the xmlns tag.
Reserved words are yucky and unnecessary though. If we want to use URIs
as a mechanism for describing an extension we can do that by using the
URI as a tag:
If the original message looks something like:
{ "a" : 1,
"b" : 2 }
We can add a new tag for the FOO extension with unique identifier
urn:iana:someregistry:FOO as follows:
{ "a" : 1,
"b" : 2,
}
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
