4 ms·

Yes, although the attacker can defer logging the certificate to CT until the moment before the certificate is used in an attack, so you would not have much time

by agwa 5y ago

Yes, although the attacker can defer logging the certificate to CT until the moment before the certificate is used in an attack, so you would not have much time to respond.

detaro 5y ago
How? The CA submits records (precertificates) to the logs before it signs the cert.
- agwa 5y ago
  Precertificates are optional. Alternatively, the CA can skip creating a precertificate. The certificate would not contain any embedded SCTs. Instead, the certificate is logged using the add-chain endpoint[1], and the returned SCTs are delivered via an extension to the TLS handshake or an extension in a stapled OCSP response[2] [1] https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 [2] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3 https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
  - deleted 5y ago
    [deleted]
  - detaro 5y ago
    thanks, I didn't know both steps (pre-cert and actual cert submission into logs) were optional.
- tialaramex 5y ago
  Logging is not a policy requirement of the trust stores. It's a condition for your certificates to work in some popular browsers (notably Chrome and Safari) but not a policy requirement. This is on purpose. Google themselves for example will get a certificate issued, say, today, for shiny-new-google-product.example and then only at the last moment do they log that certificate when spinning up the web site https://shiny-new-google-product.example/ https://shiny-new-google-product.example/ to launch shiny-new-google-product -- you can't find out about it in the CT logs because it wasn't in there earlier. Now, the readily available and especially free certificates most people use are logged before issuance as you describe using the poisoned "pre-certificate" feature from RFC 6962 (in theory this will one day be replaced by a 6962bis actual pre-certificate document rather than poisoned X.509 certs) but that is not at all mandatory, it's just convenient because it requires no workflow changes. You get a certificate, it's a bit bigger (it has SCTs baked inside it) and it just works. If you do things the hard way, you must ensure your server application software understands what SCTs are and can send them to clients as necessary. You save some bytes talking to clients that don't want the SCTs, and you get to have this just-in-time logging behaviour if you want that. The other reason it isn't against policy to issue without logging is that some archaic systems that are subject the Web PKI rules but aren't actually talking to the public Internet, and especially to web browsers, do not have logging, it's not a thing for them. This will probably go away in the next few years, these systems age out, but they still existed when I last looked.
  - detaro 5y ago
    thanks for the context, that pretty much answered all my follow-up questions. :) The "weird old systems" case sounds like something were maybe it could be required for DV-certs?
    - tialaramex 5y ago
      Logging is only valuable if it's enforced. A mandate ("You must log everything") with no enforcement ("... but we won't check") is futile. At the very most maybe it adds one more to what is likely a long list of problems with a CA during a distrust discussion. In effect there is already a requirement on CAs to internally track everything they issue, because there are numerous circumstances where the question, "What was issued with these criteria?" is pertinent and being unable to answer honestly is unacceptable. So, it doesn't make much sense to introduce logging as a policy requirement. I can't say it won't happen but I don't think it's useful. In contrast improvements to client software to actually examine SCTs in more clients and eventually to gossip about what SCTs they've seen are valuable because they improve the practical enforcement of logging. What we see today is that most incidents are logged. A CA will issue something that shouldn't exist, and independent researchers will see that in the logs, but the CA's own tools didn't discover this, not only before logging but often afterwards. Under existing policy the pre-certificate is a misissuance, even if the "real" certificate never existed we can't prove that, so the CA violated policy, but it's a problem that some of them will only realise this after it's reported by somebody else rather than flagging it immediately and self-reporting the violation. So this is reassuring because it matches my assumption that the CA operators are like most of us, they are lazy and incompetent but they aren't malevolent. They can't be bothered to do it properly, they don't remember how to do it properly, but they aren't intentionally doing a bad job, which means that they can improve if given better tools and procedures to avoid trouble.
      - detaro 5y ago
        Yes, it only makes sense if organizations monitor their domains for unexpected certificates and actually react to that, which probably not enough people do.

by agwa 5y ago

Yes, although the attacker can defer logging the certificate to CT until the moment before the certificate is used in an attack, so you would not have much time to respond.

detaro 5y ago

How? The CA submits records (precertificates) to the logs before it signs the cert.

agwa 5y ago
Precertificates are optional. Alternatively, the CA can skip creating a precertificate. The certificate would not contain any embedded SCTs. Instead, the certificate is logged using the add-chain endpoint[1], and the returned SCTs are delivered via an extension to the TLS handshake or an extension in a stapled OCSP response[2] [1] https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 https://datatracker.ietf.org/doc/html/rfc6962#section-4.1 [2] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3 https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
- deleted 5y ago
  [deleted]
- detaro 5y ago
  thanks, I didn't know both steps (pre-cert and actual cert submission into logs) were optional.
tialaramex 5y ago
Logging is not a policy requirement of the trust stores. It's a condition for your certificates to work in some popular browsers (notably Chrome and Safari) but not a policy requirement. This is on purpose. Google themselves for example will get a certificate issued, say, today, for shiny-new-google-product.example and then only at the last moment do they log that certificate when spinning up the web site https://shiny-new-google-product.example/ https://shiny-new-google-product.example/ to launch shiny-new-google-product -- you can't find out about it in the CT logs because it wasn't in there earlier. Now, the readily available and especially free certificates most people use are logged before issuance as you describe using the poisoned "pre-certificate" feature from RFC 6962 (in theory this will one day be replaced by a 6962bis actual pre-certificate document rather than poisoned X.509 certs) but that is not at all mandatory, it's just convenient because it requires no workflow changes. You get a certificate, it's a bit bigger (it has SCTs baked inside it) and it just works. If you do things the hard way, you must ensure your server application software understands what SCTs are and can send them to clients as necessary. You save some bytes talking to clients that don't want the SCTs, and you get to have this just-in-time logging behaviour if you want that. The other reason it isn't against policy to issue without logging is that some archaic systems that are subject the Web PKI rules but aren't actually talking to the public Internet, and especially to web browsers, do not have logging, it's not a thing for them. This will probably go away in the next few years, these systems age out, but they still existed when I last looked.
- detaro 5y ago
  thanks for the context, that pretty much answered all my follow-up questions. :) The "weird old systems" case sounds like something were maybe it could be required for DV-certs?
  - tialaramex 5y ago
    Logging is only valuable if it's enforced. A mandate ("You must log everything") with no enforcement ("... but we won't check") is futile. At the very most maybe it adds one more to what is likely a long list of problems with a CA during a distrust discussion. In effect there is already a requirement on CAs to internally track everything they issue, because there are numerous circumstances where the question, "What was issued with these criteria?" is pertinent and being unable to answer honestly is unacceptable. So, it doesn't make much sense to introduce logging as a policy requirement. I can't say it won't happen but I don't think it's useful. In contrast improvements to client software to actually examine SCTs in more clients and eventually to gossip about what SCTs they've seen are valuable because they improve the practical enforcement of logging. What we see today is that most incidents are logged. A CA will issue something that shouldn't exist, and independent researchers will see that in the logs, but the CA's own tools didn't discover this, not only before logging but often afterwards. Under existing policy the pre-certificate is a misissuance, even if the "real" certificate never existed we can't prove that, so the CA violated policy, but it's a problem that some of them will only realise this after it's reported by somebody else rather than flagging it immediately and self-reporting the violation. So this is reassuring because it matches my assumption that the CA operators are like most of us, they are lazy and incompetent but they aren't malevolent. They can't be bothered to do it properly, they don't remember how to do it properly, but they aren't intentionally doing a bad job, which means that they can improve if given better tools and procedures to avoid trouble.
    - detaro 5y ago
      Yes, it only makes sense if organizations monitor their domains for unexpected certificates and actually react to that, which probably not enough people do.