On 10/06/15 01:46, Matt Palmer wrote:
On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote:
On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
On 2015-06-09 15:26, Peter Kurrasch wrote:
3) How frequently might such tools run? Or to put it differently, how much time 
do I probably have between when I issue a gmail cert and when someone figures 
it out (and of course how much longer before my illegitimate cert is no longer 
valid)? I need only 24 hours to do all the damage I want, but in a pinch I'll 
make do with 8.

CT allows to store precertificate.  That is, the CA says it intents to
issue a certificate.  Should we mandate the use of precertificates and a
minimum time between the precertificate and the real certificate?

Kirk,

The reason the CT designers invented SCTs was because the CAs weren't happy with the idea of CT imposing delays on certificate issuance.

The long term hope/expectation is that precertificates will become less and less common, as more and more webservers are enhanced to support the CT TLS extension and/or OCSP Stapling. So the idea of requiring precertificates to be used is a non-starter, IMHO.

Also, note that CT is intended to help detect, not prevent, certificate misissuance.

Absolutely not. If a CA is unable to get the required minimum number of
SCTs, it will likely not issue the cert (sure, it may retry, but it's
possible that retries fail too).  Logging must be seen as intent, but not
a guarantee of issuance.

A minimum time doesn't imply a maximum (or, rather, a finite maximum).  From
your perspective, I'd object on another basis: any non-trivial delay in
issuance degrades the user experience of those acquiring certificates.  As a
consumer of CA services, I wouldn't want to have to wait (say) 3 days to get
my DV cert, just because of CT requirements.

Indeed so, Matt. That's precisely why the CAs lobbied against delays on certificate issuance.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to