Certificate Transparency
draft-laurie-pki-sunlight-12

Clearing my discuss, due to dicussion with sponsoring AD
 
the front matter should have the partiicipants affiliations.

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.

This protocol uses several OIDs from the Google vendor arc (1.3.6.1.4.1.11129).
 Should these be re-assigned somewhere under the IETF Experimental arc
(1.3.6.1.3)?

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
 (1.3.6.1.4.1.11129.2.4.3).  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 1.3.6.1.4.1.11129.2.4.4.
      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.

Thank your for addressing my concern.