7 ms·

Fantastic! Curious about revocations though - the post doesn't mention it?

by e12e 3y ago

woodruffw 3y ago
Thanks for calling this out. Revocations are not currently supported by the public API; we made a decision early in the MVP planning process to exclude them for complexity reasons. (This is consistent with Go's crypto/x509, which does not do revocation checking as part of the `Verify` API.)
- colechristensen 3y ago
  Not planned for MVP or not planned ever?
  - woodruffw 3y ago
    Not planned for the MVP, but not necessarily excluded in the future. I think it'd require a substantial design period, but that's my impression as an external contributor.
- ivanr 3y ago
  Do you think that it's possible to implement a good path building algorithm without support for revocation? For example, without revocation checking you may select a chain with a revoked certificate in it, only to discover that later. Then what? :) On the other hand, if you check the revocation status as part of the process, you can pivot to another certificate.
  - woodruffw 3y ago
    I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism. What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path building process as a dynamic search problem rather than a static one with a "single" result, any implementation you build will probably have the right "primitives" for future constraints (like revocations). [1]: https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6 https://medium.com/@sleevi_/path-building-vs-path-verifying-...
    - mcpherrinm 3y ago
      I recently gave a talk on this topic (sorry, haven't written as a blog post yet) https://www.youtube.com/watch?v=4TbtL73ibh0 https://www.youtube.com/watch?v=4TbtL73ibh0 I do believe revocation in the webpki is important to implement, but it's not great today. There are two promising paths forward, which are complementary: The simple option is short-lived certificates (7 days), which essentially don't require revocation as that's the timeline existing revocation technology can revoke on, but that has some adoption hurdles to overcome in the future. The other solution is what Mozilla is doing with CRLite: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... They are collecting all CRLs from all public web CAs and producing a small, compressed representation of all revoked certificates. That can be pushed to clients, so there's no need for any network traffic (like OCSP checks or CRL downloads) to the wide variety of CAs in the ecosystem. These "CRL Compact and Push" solutions benefit from shorter-lived certificates (eg, 90 days like Let's Encrypt does right now) because the set of revoked certs is smaller as they roll off once they expire. I suspect platform verifiers like on Windows and Mac will hopefully ship something like this in the future, though they already have CRL and OCSP fetching and caching. Non-platform verifiers like this one are really the hardest part to solve revocation. I would suggest supporting CRL checks, but that requires having disk space and caching infrastructure, which is hard for a library to know how to do universally. I think the answer is that we need to have most of our software outsource to a platform verifier, or at least some sort of system-wide revocation information cache or daemon. Maybe this means a new systemd component on Linux :)
      - ivanr 3y ago
        There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting]. All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.
        mcpherrinm 3y ago
kachnuv_ocasek 3y ago
That's a whole another can of worms.

Fantastic! Curious about revocations though - the post doesn't mention it?

by e12e 3y ago

Fantastic! Curious about revocations though - the post doesn't mention it?

Thanks for calling this out. Revocations are not currently supported by the public API; we made a decision early in the MVP planning process to exclude them for complexity reasons. (This is consistent with Go's crypto/x509, which does not do revocation checking as part of the `Verify` API.)

colechristensen 3y ago
Not planned for MVP or not planned ever?
- woodruffw 3y ago
  Not planned for the MVP, but not necessarily excluded in the future. I think it'd require a substantial design period, but that's my impression as an external contributor.
ivanr 3y ago
Do you think that it's possible to implement a good path building algorithm without support for revocation? For example, without revocation checking you may select a chain with a revoked certificate in it, only to discover that later. Then what? :) On the other hand, if you check the revocation status as part of the process, you can pivot to another certificate.
- woodruffw 3y ago
  I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism. What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path building process as a dynamic search problem rather than a static one with a "single" result, any implementation you build will probably have the right "primitives" for future constraints (like revocations). [1]: https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6 https://medium.com/@sleevi_/path-building-vs-path-verifying-...
  - mcpherrinm 3y ago
    I recently gave a talk on this topic (sorry, haven't written as a blog post yet) https://www.youtube.com/watch?v=4TbtL73ibh0 https://www.youtube.com/watch?v=4TbtL73ibh0 I do believe revocation in the webpki is important to implement, but it's not great today. There are two promising paths forward, which are complementary: The simple option is short-lived certificates (7 days), which essentially don't require revocation as that's the timeline existing revocation technology can revoke on, but that has some adoption hurdles to overcome in the future. The other solution is what Mozilla is doing with CRLite: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... They are collecting all CRLs from all public web CAs and producing a small, compressed representation of all revoked certificates. That can be pushed to clients, so there's no need for any network traffic (like OCSP checks or CRL downloads) to the wide variety of CAs in the ecosystem. These "CRL Compact and Push" solutions benefit from shorter-lived certificates (eg, 90 days like Let's Encrypt does right now) because the set of revoked certs is smaller as they roll off once they expire. I suspect platform verifiers like on Windows and Mac will hopefully ship something like this in the future, though they already have CRL and OCSP fetching and caching. Non-platform verifiers like this one are really the hardest part to solve revocation. I would suggest supporting CRL checks, but that requires having disk space and caching infrastructure, which is hard for a library to know how to do universally. I think the answer is that we need to have most of our software outsource to a platform verifier, or at least some sort of system-wide revocation information cache or daemon. Maybe this means a new systemd component on Linux :)
    - ivanr 3y ago
      There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting]. All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.
      - mcpherrinm 3y ago

kachnuv_ocasek 3y ago

That's a whole another can of worms.