Hi Ryan, On Tue, Dec 18, 2018 at 08:24:48PM -0800, Ryan Hurst via dev-security-policy wrote: > My first thought is by using SPKI you have limited the service > unnecessarily to X.509 related keys, I imagined something like this > covering PGP, JWT as well as other formats. It would be nice to see the > scope increased accordingly.
I had to use *something* to hash to get a fingerprint, and SPKI just happened to be the easiest to get out of Ruby's OpenSSL library. It's also been well-defined for a very long time and so, I hope, is fairly widely supported. Converting keys which happen to be in other formats into SPKI is a Simple Matter of Programming (or at least as simple as anything involving ASN.1 ever is). They're all the same key parameters underneath, after all (I noticed everyone seems to use the EC point encoding format from SEC 1, even). I've already written code to do SSH public keys (https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/lib/openssl/pkey.rb), and it wasn't particularly onerous. Extracting public keys out of PGP or JWK wouldn't, I presume, be a Herculean task, either. At any rate, if I'd chosen some other format to represent the data to be hashed, then I'd have needed to write code to convert from SPKI to *that* format to search for keys in certificates, so it's all much of a muchness, modulo relative distaste for particular formats. > It would be ideal if it were possible to download the database also, the > latency of the use of a third-party service while issuing certs is > potentially too much for a CA to eat at issuance time; something that > could optionally be used on-prem wouldn't leak affiliation and address > this. I don't think the security community would be overly happy if I just dumped all the keys in a tarball for world+dog to download, but I *did* consider the possibility of providing something like a bloom filter of fingerprints, for people who really need to do high-volume, low-latency lookups. I'd like to know that someone actually *wants* to do high-volume, low-latency lookups of exposed keys before I go building it (and the infrastructure for updating the filter, distributing the updates, etc), though. > As long as its limited to X.509, or at least as long as it supports it and > uses SPKI, it would be interesting to have the website use PKIjs to let > you browse to a cert, csr or key and the SPKI calculated for you. Happy > to help with that if your interested. My JavaScript skills are even worse than my Golang skills, so yeah, it would probably be better for everyone if someone else was willing to build that. The command-line querying tool I wrote (https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/bin/pwnedkeys-query) takes all X.509-key-bearing forms and SSH public keys already, but I never expected it to be the primary querying tool for anyone other than the hard-core amongst us. A more user-friendly frontend would, no doubt, be appreciated by many. > Personally I prefer https://api.pwnedkeys.com/v1/<fingerprint> to > https://v1.pwnedkeys.com/<fingerprint>. I did it that way mostly so I can run future versions of the API on separate infrastructure. The current version is very lightweight and scalable; if a future API version required more processing power to run at scale, I'd prefer to be able to manage them separately. Not everyone has Google Frontends they can put everything behind... <grin> It's a minor detail, though, and one which should impact all of about a dozen people (whoever's writing pwnedkeys querying libraries). If it turns out I was being unnecessarily pessimistic, v2 of the API can always move under `api.pwnedkeys.com`, because the URL will change anyway for every new protocol version, regardless of how it's versioned. > I see your using JWS; I had been planning on building mine on top of > Trillian (https://github.com/google/trillian) so you could have an > auditable low trust mechanism to do this. Let me know if your interested > in that and I would be happy to help there. As far as using JWS, I *really* wanted to include a signature in the attestation of compromise, so there was iron-clad proof that the key was in the control of someone who wanted to say it was pwned (hence why the signed data includes a statement to that effect, rather than a signature over some arbitrary data that could potentially be spoofed). As I mentioned in the FAQ, I first thought of formatting the signatures into X.509 certs or CSRs, but I didn't want to create any chance of confusion with legitimate X.509 objects. Also, I really don't *want* this to be an X.509-only thing, and this way I could annoy people who don't like JOSE as well as the people who don't like X.509. <grin> With regards to using Trillian (or verifiable data structures in general), given my background in working with CT, you can rest assured I spent a *lot* of time pondering how a transparency approach could provide value. Honestly, I wish I could have figured out some way to profitably use a merkle tree; I could have raised a zillion dollars putting pwned keys on the blockchain! I know Rob Stradling has made mention of the concept of "Compromised Key Transparency", but the git repo for the I-D (https://github.com/robstradling/pkct) is a bit light on content, so I don't know the lines along which he was thinking. My guess is it was probably something in the vein of revocation transparency, using a verifiable log-backed map, which is undoubtedly a neat idea, but probably not worth the hassle, at least for a v1 release of an idea nobody's really screaming for too hard. I guess in a future far, far away, when the web PKI has solved all of the many, more pressing, issues facing the community, it would be nice for certificates to have to embed what I'd call an "exclusion proof" (to show that a given certificate fingerprint *wasn't* in the map tree of exposed keys) as of a given time. I think we've all got bigger fish to fry than that just at the moment, but if there's a CA out there who wants a market differentiator, feel free to drop me a line... >From an "operator transparency" viewpoint, there's less benefits than with CT. The *need* to suppress an exposed key isn't particularly compelling; if someone wanted to wave around legal threats (or a lead pipe) to say "take that entry down", what does it get them? Maybe, in a future where CAs check pwnedkeys before issuance, someone who suppressed a key from pwnedkeys could issue a cert with an exposed key. OK... good for you, I guess? That compromised key is still out there, and I doubt it'd take very long for someone else to pop up with it and go "ahem, pwned!", the cert gets revoked, and everyone starts looking very closely at what the NSA's up to (OK, ASD, same thing). They could have just generated a whole new key (they're not rare or expensive, after all) and avoided all the scrutiny in the first place. Meanwhile, if it *was* in someone powerful's interest to suppress the fact of the exposure of a key *just* from pwnedkeys (I can think of a few possible but implausible "movie plot" type scenarios), if someone gets to me (with court order or pipe) before the key ever touches the database, how could any sort of verifiable data structure help anyone to ever know that? That's the big difference compared to CT -- "proving the negative" of "this key is definitely not exposed" is a very different problem to "this certificate has definitely been publicised". All things considered, I think applying Trillian to the problem is a nice-to-have, but is probably lower down the priority order than things like improving the collection of exposed keys from public data sources to allow more comprehensive coverage in the database. Of course, if my thinking is incomplete, I'd be very open to hearing about how Trillian (or verifiable data structures in general) could make things better. I am definitely part of the Merkle posse. <grin> > Anyways thanks for doing this. Thanks for the feedback, and I look forward to seeing what PKIjs magic you can concoct. *Absolutely* let me know what I can do to help make that happen. - Matt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
