I echo Marsh's question. Does a x509 Key Fingerprint include basicConstraints? I couldn't imagine a scenario where an attacker could get his own cert signed by a leaf cert of a website - but I also couldn't imagine New York getting hit by an earthquake ;)
Other observations: I find the Revocation section very confusingly written. > "In the event of a mismatch, clients must check whatever revocation mechanism is available and attempt to discover whether the certificate with the mismatching fingerprint has been revoked." What is the definition of mismatch? I interpreted it as no cert in the chain contains a fingerprint which matches one of the fingerprints in the pin list (supplied via prior pinned directive, or preloaded list). Therefore all certificates in the chain supplied by the site are mismatching. But seeing if they are revoked is useless, I want to check the pinned list to see if any in the pin list is revoked, so I can reevaluate the pinned list and possibly downgrade the site to 'Known HSTS Host'. But the pin list only contains fingerprints - how do I check if a cert is revoked by fingerprint? The "Interactions With Built-in HSTS Lists" section is does not cover UA updates. Should a UA update with new pin information overwrite pin information previously validly supplied by a site? Finally, I'm of the opinion that all SSL Certificate information should be exposed as javascript properties by browser. That's a bit out of scope, so I'll dial it back and say while we're working on HSTS, HSTS information should be exposed as a read-only javascript property. It doesn't need to be structured, the entire contents of the header is sufficient, similar to document.cookie. This would allow at least two more (optional) defensive practices: 1) Plugin/Extension/Greasemonkey authors could produce something like HTTPSEverywhere or NoScript that could preload pins in a method similar to preloaded pins in a UA. If a site sent a pin list that didn't match the preloaded pin list, the extension could show a warning, error, or some alert. Although similar to preloaded pins, this would not require a UA to do work, nor would it require a UA to supply a user interface to bulk-load pins. 2) Site authors could include checks in javascript to check their pinned list. While this *is* an arms race, and any javascript that is already being middled by an attacker *could* be rewritten - in practice, javascript can be sufficently obfuscated to raise the barrier to exploitation (see gmail's javascript for example). -tom
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
