You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think if we want to support certificate pinning we should use a JSON representation of the data model of RFC 7469. That way the auto configuration document could be used to "bootstrap" certificate pinning for the services (possibly not only HTTP based services, but all of them).
The only weak points would be (the initial connections to) the Webfinger & configuration document endpoints then.
The text was updated successfully, but these errors were encountered:
Here is a proposal of how the pinning property could look like. A service record MAY have a "public-key-pins" member that's an array of "pin" objects. Each pin object has a "hash-algorithm", a "hash-value" and a "max-age" and optionally a "report-only" and "report-uri" member.
The current draft has a
certificate
member, presumably to support some kind of certificate pinning.Since the latest draft has been published a new RFC has been published to specify a Public Key Pinning Extension for HTTP (RFC 7469).
I think if we want to support certificate pinning we should use a JSON representation of the data model of RFC 7469. That way the auto configuration document could be used to "bootstrap" certificate pinning for the services (possibly not only HTTP based services, but all of them).
The only weak points would be (the initial connections to) the Webfinger & configuration document endpoints then.
The text was updated successfully, but these errors were encountered: