On 9/13/2011 8:10 AM, Tom Ritter wrote:
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?
I don't understand this either. I thought that if a subsequent HTTPS
connection was established and none of the certificates in the chain
matched any of the fingerprints, then the connection was closed (with no
way for the user to override this).
Is it the case that the model is for the UA to store the actual
certificates associated with each fingerprint? This is the only way that
I can see for the UA to determine which certificates have been revoked.
Does this proposal also support self-signed certificates? I.e. if you
connect to a site, accept the self-signed certificate, can that site
then pin itself using that self-signed cert? I.e. can the validation of
the cert chain stop as soon as there is a pin match?
Philip
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
