Issue 98100043: RFC6962-bis issue #2: log submitters should verify SCTs (Closed)
|
Created:
9 years, 11 months ago by Eran Modified:
9 years, 11 months ago CC:
ctlog-opensource-review_google.com Visibility:
Public. |
DescriptionRFC6962-bis issue #2: log submitters should verify SCTs
Patch Set 1 #
Total comments: 4
Patch Set 2 : Addressing review comments #
Total comments: 1
Patch Set 3 : Indicating submitters do not have to verify SCT with an unknown format #MessagesTotal messages: 13
https://codereview.appspot.com/98100043/diff/1/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/98100043/diff/1/doc/rfc6962-bis.xml#newcode836 doc/rfc6962-bis.xml:836: If the <spanx style="verb">sct_version</spanx> is not v1, then a v1 client may be unable to verify the signature. It MUST NOT construe this as an error. This is to avoid forcing an upgrade of compliant v1 clients which do not use the returned SCTs. s/which/that https://codereview.appspot.com/98100043/diff/1/doc/rfc6962-bis.xml#newcode1102 doc/rfc6962-bis.xml:1102: Submitters submit certificates or Precertificates to the log as described above. They may go on to use the returned SCT to construct a certificate or use it directly in a TLS handshake. When the returned SCT is intended to be used this way, the log client SHOULD verify it first. "to be used _this way_" is singular, but you mention two ways in the previous sentence: "construct a certificate" and "directly in a TLS handshake". "verify it" needs unpacking, so that it's clear to an uninformed reader exactly what needs to be verified. I suggest copying some of the text from the adjacent section on TLS Clients. How about rewording this paragraph as follows... "Submitters submit certificates and Precertificates to logs as described above. When a Submitter intends to use the returned SCT directly in a TLS handshake or to construct a certificate, they SHOULD validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key."
Sign in to reply to this message.
PTAL. https://codereview.appspot.com/98100043/diff/1/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/98100043/diff/1/doc/rfc6962-bis.xml#newcode836 doc/rfc6962-bis.xml:836: If the <spanx style="verb">sct_version</spanx> is not v1, then a v1 client may be unable to verify the signature. It MUST NOT construe this as an error. This is to avoid forcing an upgrade of compliant v1 clients which do not use the returned SCTs. On 2014/05/09 10:11:46, Rob Stradling wrote: > s/which/that Done. https://codereview.appspot.com/98100043/diff/1/doc/rfc6962-bis.xml#newcode1102 doc/rfc6962-bis.xml:1102: Submitters submit certificates or Precertificates to the log as described above. They may go on to use the returned SCT to construct a certificate or use it directly in a TLS handshake. When the returned SCT is intended to be used this way, the log client SHOULD verify it first. On 2014/05/09 10:11:46, Rob Stradling wrote: > "to be used _this way_" is singular, but you mention two ways in the previous > sentence: "construct a certificate" and "directly in a TLS handshake". > > "verify it" needs unpacking, so that it's clear to an uninformed reader exactly > what needs to be verified. I suggest copying some of the text from the adjacent > section on TLS Clients. > > How about rewording this paragraph as follows... > "Submitters submit certificates and Precertificates to logs as described above. > When a Submitter intends to use the returned SCT directly in a TLS handshake or > to construct a certificate, they SHOULD validate the SCT by computing the > signature input from the SCT data as well as the certificate and verifying the > signature, using the corresponding log's public key." Definitely clearer - and to avoid violating the DRY principle, I've simply linked to the next section.
Sign in to reply to this message.
On 2014/05/09 11:59:50, Eran wrote: > PTAL. <snip> LGTM
Sign in to reply to this message.
https://codereview.appspot.com/98100043/diff/20001/doc/rfc6962-bis.xml File doc/rfc6962-bis.xml (right): https://codereview.appspot.com/98100043/diff/20001/doc/rfc6962-bis.xml#newcod... doc/rfc6962-bis.xml:1102: Submitters submit certificates or Precertificates to the log as described above. When a Submitter intends to use the returned SCT directly in a TLS handshake or to construct a certificate, they SHOULD validate the SCT as described in <xref target="tls_clients"/>. Hmm. I think the requirement should be that they should verify if they know how, but can go on to use it if the version number is higher than the one they know.
Sign in to reply to this message.
On 2014/05/14 13:17:09, Ben Laurie (Google) wrote: > https://codereview.appspot.com/98100043/diff/20001/doc/rfc6962-bis.xml > File doc/rfc6962-bis.xml (right): > > https://codereview.appspot.com/98100043/diff/20001/doc/rfc6962-bis.xml#newcod... > doc/rfc6962-bis.xml:1102: Submitters submit certificates or Precertificates to > the log as described above. When a Submitter intends to use the returned SCT > directly in a TLS handshake or to construct a certificate, they SHOULD validate > the SCT as described in <xref target="tls_clients"/>. > Hmm. I think the requirement should be that they should verify if they know how, > but can go on to use it if the version number is higher than the one they know. add-chain and add-pre-chain return the components of the SCT, not the complete encoded SCT. So, if the version "is higher than the one they know", how would they know how to construct the complete encoded SCT? (If they can't construct it, then they can't use it!)
Sign in to reply to this message.
On 14 May 2014 15:34, <robstrad@gmail.com> wrote: > On 2014/05/14 13:17:09, Ben Laurie (Google) wrote: >> >> https://codereview.appspot.com/98100043/diff/20001/doc/rfc6962-bis.xml >> File doc/rfc6962-bis.xml (right): > > > > https://codereview.appspot.com/98100043/diff/20001/doc/rfc6962-bis.xml#newcod... >> >> doc/rfc6962-bis.xml:1102: Submitters submit certificates or > > Precertificates to >> >> the log as described above. When a Submitter intends to use the > > returned SCT >> >> directly in a TLS handshake or to construct a certificate, they SHOULD > > validate >> >> the SCT as described in <xref target="tls_clients"/>. >> Hmm. I think the requirement should be that they should verify if they > > know how, >> >> but can go on to use it if the version number is higher than the one > > they know. > > add-chain and add-pre-chain return the components of the SCT, not the > complete encoded SCT. Yeah. This is perhaps a mistake. Or, at least, maybe we should add calls that allow the client to be ignorant of the internals of the SCT? > So, if the version "is higher than the one they know", how would they > know how to construct the complete encoded SCT? (If they can't > construct it, then they can't use it!) > > https://codereview.appspot.com/98100043/ -- Certificate Transparency is hiring! Let me know if you're interested.
Sign in to reply to this message.
On 2014/05/15 10:55:28, Ben Laurie (Google) wrote: > On 14 May 2014 15:34, <mailto:robstrad@gmail.com> wrote: <snip> >> add-chain and add-pre-chain return the components of the SCT, not the >> complete encoded SCT. > > Yeah. This is perhaps a mistake. Or, at least, maybe we should add > calls that allow the client to be ignorant of the internals of the > SCT? I think we should. If we're changing any calls, then do we also need to change every occurrence of... https://<log server>/ct/v1 ...to... https://<log server>/ct/v2 ?
Sign in to reply to this message.
On 15 May 2014 12:17, <robstrad@gmail.com> wrote: > On 2014/05/15 10:55:28, Ben Laurie (Google) wrote: >> >> On 14 May 2014 15:34, <mailto:robstrad@gmail.com> wrote: > > <snip> > >>> add-chain and add-pre-chain return the components of the SCT, not the >>> complete encoded SCT. > > >> Yeah. This is perhaps a mistake. Or, at least, maybe we should add >> calls that allow the client to be ignorant of the internals of the >> SCT? > > > I think we should. > > If we're changing any calls, then do we also need to change every > occurrence of... > https://<log server>/ct/v1 > ...to... > https://<log server>/ct/v2 > > ? If we add new calls rather than change existing ones, then I don't think so... -- Certificate Transparency is hiring! Let me know if you're interested.
Sign in to reply to this message.
OK. So can we tweak the proposed text to something like... "...they SHOULD validate the SCT as described in <xref target="tls_clients"/> if they understand its format." ...and then close this issue?
Sign in to reply to this message.
On 15 May 2014 12:51, <robstrad@gmail.com> wrote: > OK. So can we tweak the proposed text to something like... > > "...they SHOULD validate the SCT as described in <xref > target="tls_clients"/> if they understand its format." > > ...and then close this issue? Sounds OK to me. > > https://codereview.appspot.com/98100043/ -- Certificate Transparency is hiring! Let me know if you're interested.
Sign in to reply to this message.
On 2014/05/15 15:56:36, Ben Laurie (Google) wrote: > On 15 May 2014 12:51, <mailto:robstrad@gmail.com> wrote: > > OK. So can we tweak the proposed text to something like... > > > > "...they SHOULD validate the SCT as described in <xref > > target="tls_clients"/> if they understand its format." > > > > ...and then close this issue? > > Sounds OK to me. Done. > > > > > https://codereview.appspot.com/98100043/ > > > > -- > Certificate Transparency is hiring! Let me know if you're interested.
Sign in to reply to this message.
On 2014/05/21 15:34:39, Eran wrote: > On 2014/05/15 15:56:36, Ben Laurie (Google) wrote: > > On 15 May 2014 12:51, <mailto:robstrad@gmail.com> wrote: > > > OK. So can we tweak the proposed text to something like... > > > > > > "...they SHOULD validate the SCT as described in <xref > > > target="tls_clients"/> if they understand its format." > > > > > > ...and then close this issue? > > > > Sounds OK to me. > Done. > > > > > > > > https://codereview.appspot.com/98100043/ > > > > > > > > -- > > Certificate Transparency is hiring! Let me know if you're interested. Pushed as https://github.com/google/certificate-transparency/commit/d215e581ff59f51d132...
Sign in to reply to this message.
|
