On Wed, 19 Dec 2018 05:09:11 -0600, Rob Stradling wrote: > 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?
Yes, that's right. I'm not doing exhaustive checks of SPKIs at present, but the intention is to provide hashes for the canonically correct form(s) of keys. NIST EC keys annoying have *two* canonical forms (compressed and uncompressed point), and I've taken the approach of listing the key under both hashes, for completeness. However, where there's only *supposed* to be one form of key, that's all I'm providing a hash for in the API. Frontends can do the heavy lifting of detecting incorrect key encodings, and either refuse to proceed, or try and do a patch job to get a key to query. > 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 I mentioned in my reply to Hector, a raw dump of the existing keys (or, rather, fingerprints thereof) is a low(ish) priority. There's lots of more important things to be working on at the moment, and this is only a spare-time project. Scrapers first! > This was the gist of the idea: > https://www.mail-archive.com/trans@ietf.org/msg02705.html Unfortunately that doesn't really give much in the "why" and "how" dimensions, either. I'd love it if you could expand on what benefits a verifiable data structure provides, in your opinion, over and above a straightforward database. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
