Subject: [therightkey] Fwd: Changes to draft-laurie-pki-sunlight-07.txt

From: Emilia Kasper <[email-masked]>
Date: Fri, 22 Feb 2013 11:19:45 +0100

---------- Forwarded message ----------
From: Emilia Kasper <[email-masked]>
Date: Fri, Feb 22, 2013 at 11:19 AM
Subject: Changes to draft-laurie-pki-sunlight-07.txt
To: [email-masked]

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