4 ms·

BTW what is the need for a CA to remember issued certificates? Certificates should work as long as they are not expired, not on a CRL, and while the same appli

by nine_k 2y ago

BTW what is the need for a CA to remember issued certificates? Certificates should work as long as they are not expired, not on a CRL, and while the same applies to their.CA's certificate used to sign it. The only good use for remembering issued certificates that I see is that a CA could detect a compromise if it's handed a certificate it does not remember issuing. It looks far-fetched to me, but I know nothing about CA operation.

phasmantistes 2y ago
CAs need to know every certificate they've issued so that a) if they receive a request to revoke that certificate, they can actually do so; and b) if they need to revoke all of their certs (e.g. due to discovering a validation process failure) they don't miss any.
- masklinn 2y ago
  Isn't it more "a lot" of certs? Surely if they need to revoke all certs they can just revoke the intermediate.
  - patrakov 2y ago
    There is a middle ground between "all certs" and "a few certs". An example would be https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/114864 https://community.letsencrypt.org/t/revoking-certain-certifi... (2.4% of all certificates). This needs a full list of affected certificates but is too small to revoke the intermediate.
    - masklinn 2y ago
      > There is a middle ground between "all certs" and "a few certs". And the GP used the word "all" which is what I was replying to.
  - layer8 2y ago
    Case (b) is problematic anyway in the general case, since for timestamped signed data the revocation time is relevant, because signatures provably created before the revocation time remain valid, and at least for OCSP a published revocation time is not allowed to precede the publication of earlier “good” revocation data for the same certificate. (For CRL this constraint is merely recommended, not strictly mandated.) This means you can’t retroactively revoke certificates for times in the past, and hence your original validation procedure better be valid. In the same context, revoking the intermediate CA is bad in case some issued certificates were valid for an initial period, because then clients are unable to obtain fresh revocation information about issued certificates that would indicate the respective time of revocation (because the intermediate CA has to remain valid in order to be able to validate the signature on the OCSP response or CRL). This is mostly not a concern in the context of TLS validation, because that usually relates only to the present time, not to times in the past, but it is relevant for code signing or other electronic signature use cases.
- magicalhippo 2y ago
  > b) if they need to revoke all of their certs (e.g. due to discovering a validation process failure) they don't miss any. Dumb q, but why not just revoke/invalidate the signing certificate used to sign the certificates?
agwa 2y ago
When a CA has an incident, such as learning that one of their domain validation methods is flawed, they need to be able revoke all certificates impacted by the incident. Without a reliable database of certificates, there's no guarantee they'll find all of the impacted certificates. OCSP could fail closed in this situation. CRLs always fail open. Aside: it was in fact envisioned that OCSP could be used to detect CA compromises, and the BRs used to say "The CA SHOULD monitor the OCSP responder for requests for 'unused' serial numbers as part of its security response procedures." I'm not sure how many CAs actually implemented that, and in any case I don't think it ever detected any compromises.
- nashashmi 2y ago
  This central authority for certificate validation seems like extra infrastructure without which the internet fails. Once upon a time, internet communication was between two computers. Now there is a third computer to verify that the communication between two computers is legitimate. Is there another communication design that works without the need for a third computer? Edit: I don't think so. Identity validation of a public computer should be done by another well-trusted computer.
  - devman0 2y ago
    Could dust off DANE here, the connection probably already included a DNS lookup, why not get the public key info from the same.
    - tptacek 2y ago
      So many reasons, but the simplest is that those lookups will constantly fail because middleboxes makes variegated inane decisions about 53/udp and 53/tcp, which means you need to have a fallback mechanism, which will inevitably be exploitable. DANE is a dead letter.
  - nine_k 2y ago
    Between two distrusting parties, a third mediating party is needed. But that party does not need to be centralized. Indeed, there are many TLS certificate registrars.
fragmede 2y ago
it's exactly that. the thing is that if you're a CA, that's not farfetched at all.

by nine_k 2y ago

phasmantistes 2y ago

CAs need to know every certificate they've issued so that a) if they receive a request to revoke that certificate, they can actually do so; and b) if they need to revoke all of their certs (e.g. due to discovering a validation process failure) they don't miss any.

masklinn 2y ago
Isn't it more "a lot" of certs? Surely if they need to revoke all certs they can just revoke the intermediate.
- patrakov 2y ago
  There is a middle ground between "all certs" and "a few certs". An example would be https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/114864 https://community.letsencrypt.org/t/revoking-certain-certifi... (2.4% of all certificates). This needs a full list of affected certificates but is too small to revoke the intermediate.
  - masklinn 2y ago
    > There is a middle ground between "all certs" and "a few certs". And the GP used the word "all" which is what I was replying to.
- layer8 2y ago
  Case (b) is problematic anyway in the general case, since for timestamped signed data the revocation time is relevant, because signatures provably created before the revocation time remain valid, and at least for OCSP a published revocation time is not allowed to precede the publication of earlier “good” revocation data for the same certificate. (For CRL this constraint is merely recommended, not strictly mandated.) This means you can’t retroactively revoke certificates for times in the past, and hence your original validation procedure better be valid. In the same context, revoking the intermediate CA is bad in case some issued certificates were valid for an initial period, because then clients are unable to obtain fresh revocation information about issued certificates that would indicate the respective time of revocation (because the intermediate CA has to remain valid in order to be able to validate the signature on the OCSP response or CRL). This is mostly not a concern in the context of TLS validation, because that usually relates only to the present time, not to times in the past, but it is relevant for code signing or other electronic signature use cases.
magicalhippo 2y ago
> b) if they need to revoke all of their certs (e.g. due to discovering a validation process failure) they don't miss any. Dumb q, but why not just revoke/invalidate the signing certificate used to sign the certificates?

agwa 2y ago

When a CA has an incident, such as learning that one of their domain validation methods is flawed, they need to be able revoke all certificates impacted by the incident. Without a reliable database of certificates, there's no guarantee they'll find all of the impacted certificates. OCSP could fail closed in this situation. CRLs always fail open. Aside: it was in fact envisioned that OCSP could be used to detect CA compromises, and the BRs used to say "The CA SHOULD monitor the OCSP responder for requests for 'unused' serial numbers as part of its security response procedures." I'm not sure how many CAs actually implemented that, and in any case I don't think it ever detected any compromises.

nashashmi 2y ago
This central authority for certificate validation seems like extra infrastructure without which the internet fails. Once upon a time, internet communication was between two computers. Now there is a third computer to verify that the communication between two computers is legitimate. Is there another communication design that works without the need for a third computer? Edit: I don't think so. Identity validation of a public computer should be done by another well-trusted computer.
- devman0 2y ago
  Could dust off DANE here, the connection probably already included a DNS lookup, why not get the public key info from the same.
  - tptacek 2y ago
    So many reasons, but the simplest is that those lookups will constantly fail because middleboxes makes variegated inane decisions about 53/udp and 53/tcp, which means you need to have a fallback mechanism, which will inevitably be exploitable. DANE is a dead letter.
- nine_k 2y ago
  Between two distrusting parties, a third mediating party is needed. But that party does not need to be centralized. Indeed, there are many TLS certificate registrars.

fragmede 2y ago

it's exactly that. the thing is that if you're a CA, that's not farfetched at all.