Hacker News Reader

Comment by CobrastanJorji | Hacker News Reader

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.

View on HN

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.

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!

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.

> 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...

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 )

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.

Ah good, so mozilla::pkix is the newest one and I don't have to worry about that being replaced by something else instead.

Reply on news.ycombinator.com