On 05/15/2016 04:04 PM, Jeffrey Walton wrote:
can petition to get fixed), rather than spec bug (that we all have to
workaround).
It depends on the issuing policies.
The IETF has no way to specify that a certificate was created or
issued under PKIX, so its a moot point. (It creates a vaccum like the
EV mess, except for standard certificates rather than EV
certificates).
HPKP is specified in terms of RFC 5280, so we can assume only PKIX
certificates are used for HPKP....
In that case, the IETF provides a document on path building and
validation (RFC 4158), but not certificate validation (modulo RFC
6125). As far as I can tell, its still the wild, wild west with no
guidance on end-entity certificate validation.
Jeff
DANE is better anyway.
HPKP is trust on first use, and even worse, trust on first use without
user interaction.
DANE is validate on every use
HPKP only works with https
DANE works with anything tcp or udp
HPKP can be used for a DOS attack. Simple DNS cache poison and send the
header with a bogus set of keypins and long TTL
DANE validates via DNSSEC avoiding that issue.
I do not understand browser resistance to DANE validation.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
