sleevi

> My bet is that the answers to those questions will be more favorable for NSS, even with the crappy certificate handling.

Here's the thing, the SSL libraries are so much more than "just" SSL libraries, and products that use them have to weigh a lot of things in when comparing.

- Platform abstraction layers

* NSS builds atop NSPR, which is the Netscape Portable Runtime from ye-old

* OpenSSL doesn't have much of an abstraction layer - short of perhaps BIO* hiding the nature of POSIX FDs

- Scope of what they try to do

* OpenSSL attempts to provide basic BER/DER parsing, some mid-level abstractions (eg: X509* and the related structures), a "high-level" protocol (SSL), but without any 'productization'

* NSS attempts to provide a hardware abstraction layer (PKCS#11), a full certificate verification library (for both SSL/TLS and S/MIME/CMS - multiple ones, I should add), abstract notions of 'trust domains' within multi-process and single-process servers, etc

- How much flexibility they give developers

* OpenSSL gives you enough rope to hang yourself, and many developers often do. However, at the same time, it's popularity is in part due to it's generous supply of rope

* NSS is wildly inconsistent, with public APIs being adhoc (eg: for any given object, you're lucky if you find all four functions for CRUD, and even luckier if they're internally consistent, and you hit the jackpot if they're externally consistent).

As I mentioned on Twitter, there is no doubt that the SSL state machine of NSS is probably cleaner than OpenSSL's, having worked with both. However, there's a ton of hidden magic that NSS tries to handle, by design, that makes it impossible to reason about how well something will behave, what side-effects it might have, and what the security impact might be.

For an application like Chrome, I will highlight that some of the biggest challenges we've had is in ensuring proper privilege separation when validating certificates with different trust scopes. Some connections only wish to trust certain authorities, others may be ambivalent, and yet other connections may have a mixture of 'default' authorities plus administratively configured settings. Actually ensuring the separation of these authorities is a monumental task within NSS.

That's not because NSS doesn't want to deal with that problem - no, there have been multiple, half-completed attempts to do so, which have simply introduced layer upon layer of abstraction.

NSS is an excellent piece of software for some tasks. But for security software, the last thing you want is "magic surprises", which NSS is full of. Even though the SSL state machine is possible to reason about, if you can't reason about whether or not a given certificate will be marked as "trusted", then you're still in the danger zone.

The Authority Info Access extension ( http://tools.ietf.org/html/rfc3280#section-4.2.2.1 ) can contain caIssuers field that point to URIs from which the issuer certificate may be downloaded.

In practice, there's not a "single" chain for a server. Different clients have different trust anchors, support different signing algorithms, and encounter the same certificates at different times. This has all conspired such that "Every Modern Browser" will, as necessary, examine the AIA extensions presented in the certificates and attempt to construct a valid chain, even if the server supplies an 'invalid' one.

A decent description of the complexity that modern PKI libraries (eg: browsers & OSes) implement can be found at http://social.technet.microsoft.com/wiki/contents/articles/4...

Internet Explorer, Mozilla Firefox, and Google Chrome all respect name constraints. I believe Opera does as well.

The issue is that according to RFC5280, nameConstraints MUST be marked critical, which would break all clients that don't support nameConstraints - including Apple OS X and iOS. As a result of not wanting to break these clients, no CA has practically deployed nameConstraints.

However, as is being discussed in the CA/Browser Forum AND Mozilla's security policy list (and previously, within PKIX), CAs and browsers are considering diverging from 5280, and not REQUIRING that 5280 be marked critical. ( https://groups.google.com/forum/?fromgroups#!topic/mozilla.d... for more context)

This will allow a transition period, where CAs that would otherwise NOT include nameConstraints (because it would break clients) can now safely include nameConstraints and not break the legacy or insecure clients that do not support them. Mozilla's proposed CA Certificate Inclusion Policy ( http://www.mozilla.org/projects/security/certs/policy/WorkIn... ) would REQUIRE that CAs use name constraints when issuing sub-CAs that are not audited, secured, and conformant with Mozilla's policy.

You're talking about http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep... , right? I replied, and also tried to clarify in a follow-up message on http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep...

As far as "arrange to get people in a room" - that's exactly what we're trying to do, and exactly why we solicit feedback. While the Hacker News engagement is great, and so is Twitter, I suspect that I'm missing 90% of the discussion because nobody is sending mail to where we asked - public-webcrypto-comments@w3.org - and so no one in the WG is having a chance to engage and discuss.

Again, we're not trying to design a cryptosystem here, as far as a "secure messaging protocol" goes, least of all because no one who submitted feedback during the months of time spent when it was a W3C Community Group and chartering into an actual WG did anyone actually give a use case where their needs would be met with such an API.

Definitely, the best place for concern and criticism will be the mailing list, and that's the whole point of the wide canvas and call for feedback.

  In other words, you're claiming that some few skilled 
  cryptographers will produce a safe, high-level API 
  (eventually) and the low-level API is already useful to many 
  web developers. The implication is that many web 
  developers can do something that is both useful and safe 
  with only the low-level API.

I was not trying to suggest that only the low-level API is sufficient. I think there's no question that for some segment of potential use cases, they would be unquestionably better served if their hand was held all the way through, that that the crypto protocol and exchange was fully dictated for them. I think that's true for just about any use of crypto.

However, if we only provide a so-called high-level API (what I've been terming as box/unbox, and which is conceptually similar to what Keyczar, Nacl, or even JOSE offer), then I think there's even an larger number of known and possible use cases that simply cannot be implemented. That's why I believe it's more useful to provide a low-level API.

I think perhaps there are unrealistic expectations on what this is trying to do or who this is trying to serve. It's not trying to save the world from bad crypto. It's attempting to bring to the web platform what has existed in native code for 3+ decades - pitfalls and all.

I'd also be concerned about the argument going the other way - if we only provided a high-level protocol & API, then developers would need to implement whatever protocol specified atop the existing low-level primitives (OpenSSL, PKCS#11, CNG, etc). There, just as well, the risk is that people will get it wrong - or that 'others' will write libraries to do it right. You can't escape from the fact that crypto is hard, and that there is always going to be a segment of developers who will simply not get it right.

While the trust issue you raise is legitimate, it's not one we're trying to solve (or at least, not yet, and I hope not soon)

You may ask then, "Well, what's the point of this API if you're not going to solve it?"

The answer is that solution for the trust model issues are being addressed concurrently and, unquestionably, more adequately, in other W3C working groups, the WHATWG, the IETF, and other such standards bodies. For example, the development of Content Security Policy, the hopeful formation of the Sys Apps WG, offline apps that execute in their own origin, the proposed <browser> tag, the formalization of the things as basic as the web origin concept (RFC 6454), Web Intents as a service-agnostic IPC mechanism. There are a number of efforts going on to address and enhance the overall security and utility of the platform. Our WG is providing just one small part of the overall picture.

Every concern about malleability of the run-time applies equally so when you're not doing JS crypto - native or browser-mediated. Storing something in localStorage/IndexedDB? Well, now you've got an opportunity to turn transient XSS into persistent, stored XSS. Does that mean localStorage/IndexedDB are doomed to failure or fundamentally flawed for not addressing that? No. Are cookies complete and utter garbage due to all of their known issues? No (or at least, not /complete/ ;-)

I recognize that there are a variety of security decisions and trade-offs being presented in this API, decisions that will have to be made by site authors. It may be that this is completely unacceptable - and I would hope, by now, that people feeling that way would be sending mail to public-webcrypto-comments@w3.org saying that. However, for the use cases that have been presented and expressed, the trade-offs have been understood and are, thus far, acceptable, which is why this WG has continued the path its on and why the participants have, so far, believed in the utility of the API.

As far as algorithms go, our failure (thus far) to include DSA is hardly going to be the end of SSH (for which many still use DSA keys), just like our failure (thus far) to include ElGamal or MD5 are not going to mean the death of PGP/GPG. However, by not including them, it also means that there's no way to implement such applications, even if all other concerns were controlled for - and that would suggest our API is incomplete and a less-compelling alternative. Suggesting that failing to implement PKCS#1 v1.5 will finally mean the end of it is unrealistic.

So far, our stated goal has been to produce a low-level API that has applicability for a number of situations, as captured both in the use cases of the draft and in the companion use cases wiki. The core functionality starts with "Secure key store. Secure RNG". In order to support "secure key store," it's necessary to define what you can do with these "secure" keys, hence, the specification of certain operations and algorithms.

We're not (thus far) attempting to create an enveloping format - that's something that the IETF JOSE WG is doing, and that various groups and standards ranging from XML DSig to CMS to S/MIME have done or tried to do.

We're not (thus far) attempting to create the one-true-perfectly-safe-full-of-cryptographic-kittens-and-puppies "box" and "unbox" - it's interesting, unquestionably useful, but getting two crypto-geeks, let alone a hundred, to agree on what that operation is composed of is a sisyphean effort. Should it be Sals20 or AES-GCM? Why not Blowfish? Monkey knife-fighting appears more civilized then some of those crypto-political discussions - and makes more progress to boot.

By providing the low-level API, application developers can make an informed decision on what that "box" looks like to them, or relying on cryptographically skilled developers to produce libraries (ala KeyCzar, ala NaCl) to do that for them. Yes, it also means that uninformed developers can start smashing things together and leading to wonderfully painful crypto-explosions. However, you don't see WebGL being lamented for its lack of built-in VRML support (I hope...), and neither do I think this API should include the kitchen sink, bathtub, robe, and matching slippers in order to be useful and applicable for many web developers.

Yes, screwdrivers are wonderfully useful tools, and it's fairly hard to hurt yourself with one. But sometimes you really need a hammer - or a chainsaw, or a level, or a drill - in order to do the right job. This API is merely a toolbox - dangers and all - not the One True Solution to all the Bad Crypto.

For what it's worth, while I object to your tax-and-spend approach with cupcakes, I do subscribe to your TLS-only newsletter for key-utilizing operations, and had proposed that already. Keyless operations are more of a gray area of policy rather than security. For example, should hashing require TLS? I think not, since there are non-crypto-but-still-useful applications of cryptographic hashes and random numbers (eg: name-based or PRNG-based UUIDs as described in RFC 4122). However, splitting the interface into TLS and HTTP segments is something that has its own issues.

It's possible that a compromise might be the "Secure Cookie" equivalent of specifying policy (HTTPS-only) when creating or importing keys, but I hope it doesn't come to that.

That said, I'm also a big proponent of requiring some sort of sane CSP settings to also narrow the scope of the API usage ( http://www.w3.org/2012/webcrypto/track/issues/21 ), but that remains an open issue.