Note: This ballot was opened for revision 08 and is now closed.
Stephen Farrell Yes
(Ted Lemon) Yes
Comment (2013-03-26 for -08)
It might be interesting to talk about what one of these logs would look like in practice—how big a log such as this would be for a typical CA, and what the size of a typical verification chain would be. In general I think this is a really interesting idea and I look forward to seeing some results from the experiment.
Jari Arkko No Objection
(Richard Barnes) (was Discuss) No Objection
Comment (2013-04-16 for -10)
This protocol uses several OIDs from the Google vendor arc (188.8.131.52.4.1.11129). Should these be re-assigned somewhere under the IETF Experimental arc (184.108.40.206.3)?
(Stewart Bryant) (was Discuss) No Objection
Comment (2013-04-18 for -11)
Thank your for addressing my concern.
(Gonzalo Camarillo) No Objection
(Adrian Farrel) No Objection
(Brian Haberman) No Objection
Joel Jaeggli (was Discuss) No Objection
Comment (2013-03-28 for -09)
Clearing my discuss, due to dicussion with sponsoring AD the front matter should have the partiicipants affiliations.
(Barry Leiba) No Objection
(Pete Resnick) No Objection
Comment (2013-03-27 for -09)
Blech. I hate docs written in terms of code and APIs. Makes for brittle implementations. If this thing ever gets on the standards track, I hope it is rewritten with actual data format diagrams and protocol instructions. But as an experiment: Have at it.
(Martin Stiemerling) No Objection
(Sean Turner) (was Discuss) No Objection
Comment (2013-03-28 for -09)
0) s1: According to RFC 5280: r/certificate authority/certification authority throughout 1) s3.1: Some word smithing. I think we need to clear that the poison extension must not be processed by relying parties. Alternatively, (root as well as intermediate) Certification Authorities may submit a certificate to logs prior to issuance. To do so, a Certification Authority constructs a Precertificate and adds the poison extension identified by the OID with the value of (220.127.116.11.4.1.1118.104.22.168). This extension MUST be critical and it MUST NOT be processed by relying parties. The extension's value is NULL, that is the extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00). The CA, whose basic constraints extension cA=True and key usage is set to keyCertSign) signs the resulting TBSCertificate [RFC5280] with either o the Precertificate Signing Certificate Transparency Extended Key Usage, whose OID is 22.214.171.124.4.1.11126.96.36.199. The Precertificate Signing Certificate MUST be directly certified by the (root or intermediate) CA certificate that will ultimately sign the end entity TBSCertificate yielding the end entity certificate (note that the log may relax standard validation rules to allow this, so long as the issued certificate will be valid), 2) s3.1: Is there any kind of dispute resolution if somebody tries to submit a Root CA certificate and the entity running the log says no? 3) s3.3: Need to specify whether the SignedCertificateTimestampList certificate extension is critical. 4) s4: Need to specify which alphabet your using. Is it "normal" or with URL and Filename Safe? 5) Any additional constraints on the timestamps? The syntax is: YYYYMMDDhhmmss[.s...]Z Example: 19990609001326.34352Z The encoding MUST terminate with a "Z" (which means "Zulu" time). The decimal point element, if present, MUST be the point option ".". The fractional-seconds elements, if present, MUST omit all trailing 0's; if the elements correspond to 0, they MUST be wholly omitted, and the decimal point element also MUST be omitted. 6) Why wasn't a GET/POST method described for s4.7? Whould it' be like GET https://<log server>/ct/v1/get-roots No inputs Outputs certificates An array of base64 encoded root certificates that are acceptable to the log. 7) Probably adding in s6, to make it clear what else got registered. This document also defines an X.509 Certificate EKU, two X.509 Certificate extensions as well as an OCSP extension. The Object Identifiers for these are assigned from a Google Arc and no further action is required of IANA for these values. 8) Just so I'm following along: TLS client must support all three mechanisms in s3.3, the SCT is signed by either ECDSA or RSA, so clients need to support both ECDSA and RSA? I'm fine with that just curious though. 9) Any reason to not reference FIPS 186-4? Might just be that you're using XML2RFC and it's database is out of date. [SHS] National Institute of Standards and Technology, "Federal Information Processing Standard Publication 180-4: Secure Hash Standard (SHS)", March 2012, <http://csrc.nist.gov/ publications/fips/fips180-4/fips-180-4.pdf>. 10) Yet another nitty thing about the reference to DSS for ECDSA. We've really tried to get folks to start pointing to RFC 6090. If the hash and curve are matched as they are here I've been told the outputs of RFC 6090 and DSS are the same. Any chance you could point there instead? 11) I know it's just an experiment, but do we need to have a registry policy for CtExtensions? 12) Maybe another thing for future study is how to get the log's public key to clients.