Hi Matt. This is great. A few comments inline... On 19/12/2018 09:00, Matt Palmer via dev-security-policy wrote: > 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.
How do you handle malformed SPKIs? (e.g., the algorithm parameters field for an RSA public key is missing, whereas it should be present and should contain an ASN.1 NULL). Presumably your server/database only deals with correctly encoded SPKIs, and it's up to the caller to ensure that they repair an incorrectly encoded SPKI before they call your API? >> 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. I'm wondering how I might add a pwnedkeys check to crt.sh. I think I'd prefer to have a table of SHA-256(SPKI) stored locally on the crt.sh DB. >> 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, lol. It's an empty repo! One of those back-of-a-napkin ideas that I haven't found time to develop further. This was the gist of the idea: https://www.mail-archive.com/trans@ietf.org/msg02705.html > 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 -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
