---------- Forwarded message ---------- From: Emilia Kasper <ekas...@google.com> Date: Fri, Feb 22, 2013 at 11:19 AM Subject: Changes to draft-laurie-pki-sunlight-07.txt To: draft-laurie-pki-sunli...@tools.ietf.org
Hi all, We have identified some small ambiguities/inconsistencies in the draft and propose the following fixes: * Sect. 3.1 - explicitly mention that the special-purpose Precert Issuing Certificate should be a CA certificate. (Note this certificate can be made invalid outside the context of CT by marking the Extended Key Usage extension critical.) * Sect 3.1 - "The precertificate Signing Certificate MUST be certified by the CA certificate..." could read "The precertificate Signing Certificate MUST be directly certified by the CA certificate..." for extra clarity. * Sect. 3.1 "In case of Precertificates, each log MUST also verify that the Precertificate Signing Certificate has the correct Extended Key Usage extension" is superfluous, and can be removed. A Precertificate Signing Certificate is identified as such by its EKU extension. * Sect. 3.1 We note that a log's set of accepted root certificates may change over time, so retrieving currently accepted root certificates may not suffice to determine the root certificate used to verify a certificate's issuer chain. We propose to require that logs record the root in the chain and produce it upon request (in the client message of Sect. 4.6, "Retrieve entries from Log"). That is, in Sect.3.1, "The self-signed root certificate MAY be omitted from the chain" should read "The final certificate MUST be a root certificate accepted by the log", twice. Sections 4.1 and 4.2 remain unchanged, i..e, it is not required for clients to include the root certificate in the submission. * Sect 3.2 mentions that if a Precertificate Signing Certificate is used, "the TBSCertificate also has its issuer changed to that of the CA that will issue the final certificate". We propose to clarify the handling of the Authority Key Identifier extension in this case by requiring that "if an Authority Key Identifier extension is present in the TBSCertificate, the corresponding extension must also be present in the Precertificate Signing Certificate - in this case, the TBSCertificate also has its Authority Key Identifier changed to match the final issuer". * Sect 3.4 In the TimestampedEntry structure, "case precert_entry: TBSCertificate" should read "case precert_entry: PreCert" to match what is signed in the SignedCertificateTimestamp. Best, Emilia
_______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
