3 ms·

It could certainly be the case that it's poorly designed, but it's not necessarily the case just because they've hidden the feature from the UX. First, the bac

It could certainly be the case that it's poorly designed, but it's not necessarily the case just because they've hidden the feature from the UX. First, the backend constraints may be ideal despite whether they've bothered exposing any of them in the UI. Second, not exposing them in the UI may have been an explicit design decision and not just trade-offs. It's possible that a root certificate list was deemed complicated enough without adding a zillion more hard-to-debug toggles that might allow curious users to accidentally break something in a way that would be very confusing, and only allowing programmatic access was deemed to be best because likely the settings would only be used by enterprises managing their fleet or some such.

gowld 6y ago
Even if the policy data is absent from UI for legitimate reasons, if the policy can't be programmatically extracted, the documentation can't be trusted. That is, the policy should be a declarative object interpreted by a well-tested engine, or a small simple bit of logic, not a crawl through the engine code looking for 'if' statements.
- sleevi 6y ago
  Eh, my point was just that: - Policy is largely encapsulated on the certificate properties in the root store - Local Policy is implemented via registry keys, with somewhere like 100+ odd registry keys (... many undocumented, as they implement customer-specific features whose documentation is provided under a MSFT support agreement) - Policy is a mix of documented (via WinCrypt.h) and undocumented flags - The reason for not documenting some of this is that they’re flags that Microsoft may or may not support; that is, they’re implementation details - CAPI provides, by design, several ways to fully replace their policies, either for single trust purposes or for all - The UI exposes a suitable “general purpose” expression I can totally understand the complaint that this isn’t clear in the UI, and as others have noted, sometimes that’s intentional. I can also totally understand the complaint that this isn’t all meticulously documented. Not everyone can ring up their pet Microsoft engineer to get documentation and show how it connects to a problem that Microsoft benefits from helping us solve (the linked-to crt.sh bug, which as a side-effect helps provide greater automation for Microsoft and the CAs they supervise). However, Microsoft also, from the get-go, designed it to be extensible so you could replace this. Importantly, Microsoft has been able to roll out new features, and remove trust in CAs, without major re-engineering work. That was the “beautiful engineering” part of my comment. They defined a stable API that could be easily extended, or even wholesale replaced, in the Windows 2000/XP era. That API has brought considerable improvements WITHOUT requiring rewriting your code for Windows Vista, 7, 8, or 10 to leverage that. That’s a considerable difference from some other libraries and tools; LibreSSL was hugely constrained fixing OpenSSLs broken chain building, Mozilla Firefox/NSS has undergone three complete and separate rewrites from the ground up of the engine, Apple deprecated dozens of APIs when they ported iOS’s verifier to macOS, etc. As an engineer, 20+ years of stability IS impressive!
  - throwaheyy 6y ago
    Having recently implemented some new product features using several parts of the CryptoAPI, my experience agrees. There were several instances of taking days of dead-ends to get something to work the way you wanted. Eventually finding the correct way through trial and error or some obscure example code on the internet from 10 years ago. But once you cracked it, the code and API felt like it would be rock-solid for decades to come. It’s a mess of discoverability and documentation, but as someone else in this thread said, beautifully engineered.
  - jcranmer 6y ago
    > Mozilla Firefox/NSS has undergone three complete and separate rewrites from the ground up of the engine Can you provide more details? I'm only aware of one of these rewrites...
    - sleevi 6y ago
      1. Legacy 2. Trust Domains (half completed, but littered throughout the code as nss3 prefix). This was being lead by Sun and stopped when Oracle acquired them. 3. libpkix: This was done by porting Java code to C using preprocessor macros to simulate exception handling. It implemented path discovery, and not just verification, and was used by Firefox for EV processing (AIUI), and was always used by Chrome on Linux/ChromeOS (until recently replaced with the Chromium built-in verifier) 4. mozilla::pkix, which started off as Brian Smith’s insanity::pkix rewrite of a minimalist path builder/verifier. I can’t remember if this launched while Brian was still at Mozilla or after he had left, but Brian would later take the approach he used for insanity::pkix when writing the Rust webpki project ( https://github.com/briansmith/webpki https://github.com/briansmith/webpki ) Each of the above APIs had significantly different interfaces for controlling verification. The trust domain stuff wasn’t as visible, because it was only half-completed.
      - jcranmer 6y ago
        Ah good, so mozilla::pkix is the newest one and I don't have to worry about that being replaced by something else instead.

gowld 6y ago

Even if the policy data is absent from UI for legitimate reasons, if the policy can't be programmatically extracted, the documentation can't be trusted. That is, the policy should be a declarative object interpreted by a well-tested engine, or a small simple bit of logic, not a crawl through the engine code looking for 'if' statements.

sleevi 6y ago
Eh, my point was just that: - Policy is largely encapsulated on the certificate properties in the root store - Local Policy is implemented via registry keys, with somewhere like 100+ odd registry keys (... many undocumented, as they implement customer-specific features whose documentation is provided under a MSFT support agreement) - Policy is a mix of documented (via WinCrypt.h) and undocumented flags - The reason for not documenting some of this is that they’re flags that Microsoft may or may not support; that is, they’re implementation details - CAPI provides, by design, several ways to fully replace their policies, either for single trust purposes or for all - The UI exposes a suitable “general purpose” expression I can totally understand the complaint that this isn’t clear in the UI, and as others have noted, sometimes that’s intentional. I can also totally understand the complaint that this isn’t all meticulously documented. Not everyone can ring up their pet Microsoft engineer to get documentation and show how it connects to a problem that Microsoft benefits from helping us solve (the linked-to crt.sh bug, which as a side-effect helps provide greater automation for Microsoft and the CAs they supervise). However, Microsoft also, from the get-go, designed it to be extensible so you could replace this. Importantly, Microsoft has been able to roll out new features, and remove trust in CAs, without major re-engineering work. That was the “beautiful engineering” part of my comment. They defined a stable API that could be easily extended, or even wholesale replaced, in the Windows 2000/XP era. That API has brought considerable improvements WITHOUT requiring rewriting your code for Windows Vista, 7, 8, or 10 to leverage that. That’s a considerable difference from some other libraries and tools; LibreSSL was hugely constrained fixing OpenSSLs broken chain building, Mozilla Firefox/NSS has undergone three complete and separate rewrites from the ground up of the engine, Apple deprecated dozens of APIs when they ported iOS’s verifier to macOS, etc. As an engineer, 20+ years of stability IS impressive!
- throwaheyy 6y ago
  Having recently implemented some new product features using several parts of the CryptoAPI, my experience agrees. There were several instances of taking days of dead-ends to get something to work the way you wanted. Eventually finding the correct way through trial and error or some obscure example code on the internet from 10 years ago. But once you cracked it, the code and API felt like it would be rock-solid for decades to come. It’s a mess of discoverability and documentation, but as someone else in this thread said, beautifully engineered.
- jcranmer 6y ago
  > Mozilla Firefox/NSS has undergone three complete and separate rewrites from the ground up of the engine Can you provide more details? I'm only aware of one of these rewrites...
  - sleevi 6y ago
    1. Legacy 2. Trust Domains (half completed, but littered throughout the code as nss3 prefix). This was being lead by Sun and stopped when Oracle acquired them. 3. libpkix: This was done by porting Java code to C using preprocessor macros to simulate exception handling. It implemented path discovery, and not just verification, and was used by Firefox for EV processing (AIUI), and was always used by Chrome on Linux/ChromeOS (until recently replaced with the Chromium built-in verifier) 4. mozilla::pkix, which started off as Brian Smith’s insanity::pkix rewrite of a minimalist path builder/verifier. I can’t remember if this launched while Brian was still at Mozilla or after he had left, but Brian would later take the approach he used for insanity::pkix when writing the Rust webpki project ( https://github.com/briansmith/webpki https://github.com/briansmith/webpki ) Each of the above APIs had significantly different interfaces for controlling verification. The trust domain stuff wasn’t as visible, because it was only half-completed.
    - jcranmer 6y ago
      Ah good, so mozilla::pkix is the newest one and I don't have to worry about that being replaced by something else instead.