Can a SCT for a PreCert used in an OCSP staple?

190 views
Skip to first unread message

Santhan Raj

unread,
Sep 26, 2017, 3:48:15 AM9/26/17
to certificate-transparency
Hello,

Section 3.4 of RFC 6962 states that the signature includes entry_type. And a little further down, it states that 

"entry_type" may be implicit from the context in which the SCT is presented.

So would Chrome reject a pre-cert's sct, if it was presented in an OCSP response for the actual EE cert?

Thanks,
Santhan

Rob Percival

unread,
Sep 26, 2017, 3:54:21 AM9/26/17
to certificate-...@googlegroups.com

Yes, Chrome would reject that. You need to log the EE  cert and use those SCTs in the OCSP staple. The same is true for the TLS extension. Pre-cert SCTs are only suitable for embedding in the EE cert.


--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rijad Muminović

unread,
Sep 26, 2017, 6:58:47 AM9/26/17
to certificate-transparency
Hey Santhan,

Indeed Rob is right that it would be rejected by Chrome, as any SCT that is not embedded in the certificate itself will be considered to be signed over the EE cert log entry.

I would just like to add an example of a website using (at least is today) the same SCTs embedded in the cert and then stapled in an OCSP response: https://swisscare.com/
Inspecting it, in Chrome's security tab in devtools, shows that the SCTs are the same for embedded and OCSP, and that the OCSP ones have an invalid signature.

Santhan Raj

unread,
Sep 26, 2017, 11:45:44 AM9/26/17
to certificate-transparency
Thank you both for confirming. Can you also please help me understand why this behavior is desired/required. I.e., is there a risk with using a PreCert's SCT in place of a EE's given the TBS should be the same in both cases? 

Thanks,
Santhan

Rob Percival

unread,
Nov 13, 2017, 10:45:36 AM11/13/17
to certificate-transparency
I don't think there's a risk, but it would have required either:
  • an extra field in the SCT (the "entry_type").
  • clients trying to verifying SCTs twice; once as a precert SCT, then again as an x509 SCT if that fails.
I can't see a benefit that would justify either of those.

Tom Ritter

unread,
Nov 13, 2017, 10:53:17 AM11/13/17
to certificate-transparency
On 26 September 2017 at 05:55, 'Rijad Muminović' via
certificate-transparency <certificate-...@googlegroups.com>
wrote:
> Hey Santhan,
>
> Indeed Rob is right that it would be rejected by Chrome, as any SCT that is
> not embedded in the certificate itself will be considered to be signed over
> the EE cert log entry.
>
> I would just like to add an example of a website using (at least is today)
> the same SCTs embedded in the cert and then stapled in an OCSP response:
> https://swisscare.com/
> Inspecting it, in Chrome's security tab in devtools, shows that the SCTs are
> the same for embedded and OCSP, and that the OCSP ones have an invalid
> signature.

That is weird, and still happening. Does anyone know why?

I asked in August if a log could return a PreCert in response to
add-chain (https://www.mail-archive.com/tr...@ietf.org/msg02708.html)
and they can't, so the only way I think this could happen is for the
OCSP responder to be pulling the SCTs out of the certificate and
copying them into the OCSP response.

-tom

corneli...@gmail.com

unread,
Nov 17, 2017, 9:31:32 AM11/17/17
to certificate-transparency
Hello,

SwissSign has done some investigation regarding the affected certifcate and opend a separate response to this under:

connie
Reply all
Reply to author
Forward
0 new messages