5 ms·

Except, most CAs aren't required to publish all certs to CT. Symantec is specifically required to because of hanky-panky in their past.

by azdle 10y ago

hannob 10y ago
It's a bit more complex, but you have a point. For EV CAs are already required to submit them to CT. Soon this requirement will be extended to all certs (October 2017). In practice almost all certificates are already in a CT log, because the google crawlers submit them. But you're right: If it's about certificates purely generated for test purposes it could be that CAs that don't do CT yet can hide that.
- epistasis 10y ago
  Or if it's a second cert generated for somebody else's site (like the example.com was), and only used for targeted MITM, then it likely won't ever make it into to CT either. I.e. the actual bad certs won't make it in there unless there's required posting to CT. Is there a way to revoke a cert without knowing the actual signature? For example, if there are holes in the serial number sequence, does any current revocation scheme allow revoking that number, or, any serial numbers that have not yet been submitted to CT?
  - pfg 10y ago
    OCSP and CRLs both work based on specific serial numbers. Serial numbers are not really sequential either (a portion of it has to be random). The closest thing to what you're describing would be the Expect-CT HTTP header[1] which can be used by site operators to instruct browsers to always expect a CT-logged certificate from the site (or more specifically, to expect qualified SCTs to be provided for the site's certificate). I believe this feature is planned for Chrome 58 if I'm reading the ticket correctly[2]. Presumably, this will be available as a preloaded flag for domains at some point as well (like HSTS preloading). [1]: https://tools.ietf.org/html/draft-stark-expect-ct-01 https://tools.ietf.org/html/draft-stark-expect-ct-01 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=679012 https://bugs.chromium.org/p/chromium/issues/detail?id=679012

Except, most CAs aren't required to publish all certs to CT. Symantec is specifically required to because of hanky-panky in their past.

by azdle 10y ago

Except, most CAs aren't required to publish all certs to CT. Symantec is specifically required to because of hanky-panky in their past.

hannob 10y ago

It's a bit more complex, but you have a point. For EV CAs are already required to submit them to CT. Soon this requirement will be extended to all certs (October 2017). In practice almost all certificates are already in a CT log, because the google crawlers submit them. But you're right: If it's about certificates purely generated for test purposes it could be that CAs that don't do CT yet can hide that.

epistasis 10y ago
Or if it's a second cert generated for somebody else's site (like the example.com was), and only used for targeted MITM, then it likely won't ever make it into to CT either. I.e. the actual bad certs won't make it in there unless there's required posting to CT. Is there a way to revoke a cert without knowing the actual signature? For example, if there are holes in the serial number sequence, does any current revocation scheme allow revoking that number, or, any serial numbers that have not yet been submitted to CT?
- pfg 10y ago
  OCSP and CRLs both work based on specific serial numbers. Serial numbers are not really sequential either (a portion of it has to be random). The closest thing to what you're describing would be the Expect-CT HTTP header[1] which can be used by site operators to instruct browsers to always expect a CT-logged certificate from the site (or more specifically, to expect qualified SCTs to be provided for the site's certificate). I believe this feature is planned for Chrome 58 if I'm reading the ticket correctly[2]. Presumably, this will be available as a preloaded flag for domains at some point as well (like HSTS preloading). [1]: https://tools.ietf.org/html/draft-stark-expect-ct-01 https://tools.ietf.org/html/draft-stark-expect-ct-01 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=679012 https://bugs.chromium.org/p/chromium/issues/detail?id=679012