Tomas
From: von Oheimb, David
Sent: Friday, October 7, 2022 7:21 PM
To: pgut...@cs.auckland.ac.nz ;
Mike.Ounsworth=40entrust@dmarc.ietf.org
; john.g...@entrust.com
; tim.holleb...@digicert.com
; Tomas Gustavsson
Cc: morgan...@dataio.com ; sp...@ietf.org
ilt into the ACME protocol for example, that could work. Especially since
ACME keeps some state anyhow already.
____
From: Tomas Gustavsson
Sent: Friday, October 7, 2022 9:16 AM
To: von Oheimb, David ; john.g...@entrust.com
; Mike.Ounsworth=40entrust@dmarc.ietf
Thursday, October 6, 2022 9:17 PM
To: john.g...@entrust.com ;
Mike.Ounsworth=40entrust....@dmarc.ietf.org
; Tomas Gustavsson
Cc: morgan...@dataio.com ; t...@thomwiggers.nl
; sp...@ietf.org ; tls@ietf.org
; u...@ll.mit.edu
Subject: Re: [lamps] [EXTERNAL] Re: [TLS] Q: Creating CSR for encr
> That said, I believe CT is not actually problematic because public CAs
> (typically? always?) publish precerts in the SCT which are only the
> TBSCertificate with no CA signature, so
> the CT log does not actually contain enough data to successfully respond to
> the PoP challenge
That is no
For CT logs as in 'CT used for public web sites' there is no possibility to
delay submitting. The only currently used mechanism is submission to CT logs of
pre-certificates, before the final certificate is signed. So CT log entries
will always be there, and so must the final certificate be issue
