The Announcement Signed Certificate Timestamps embedded in certificates is incorrect. Since the certificate can not contain an singed proof that really this certificate was submitted. It can only contain an proof that an pre-unsinged version of it was submitted. Since the real certificate contain the signature and after signing it can not be added with the proof that it is committed. It is an classical “hen and egg” problem. So @jsha should be more clear in the description.
Maybe a link on that post to something explaining how precertificates work would help 
.
Thanks @tlussnig! You’re right that my original post was inaccurate on that point. I have tweaked the wording slightly to say that “a corresponding precertificate” was logged. What do you think?
Yes it is more clear. If the sentence " Starting soon, we will provide that proof by embedding Signed Certificate Timestamps (SCTs) in each newly issued certificate." would also be replaced to " Starting soon, we will provide an proof that an precertificate was submitted by embedding Signed Certificate Timestamps (SCTs) in each newly issued certificate." It would be exact. I am only so detailed because i know that in security area even the smallest derivation from the specification can cause big issues. So also the descriptions should be accurate.
Pedantically speaking, your comment is absolutely true.
Having said that, the SCTs cover signature over a precertificate comprised of a set of TBSCertificate data which is deterministically related to the final certificate in as far as it represents the data that will fill the actual certificate – in a cryptographically assurable way.
In as far as that the message was meant for users, I’m not sure adding more specificity here helps anyone, but I suppose it probably doesn’t hurt either.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.