-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting the fingerprint of an RTCCertificate #738
Conversation
Fix for Issue #720
@@ -3657,6 +3657,7 @@ <h2 id="sec.cert-mgmt">Certificate Management</h2> | |||
<div> | |||
<pre class="idl">interface RTCCertificate { | |||
readonly attribute DOMTimeStamp expires; | |||
readonly attribute RTCDtlsFingerprint fingerprint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And what if we want to include two hash functions?
Imagine that in the future we end up with a weak and strong hash algo during a transition time period and it is possible to cause collisions in the weak one. It seems like if one side will except the weak, then this open up for a MITM attack where the attacker takes the strong hash, then compute a weak hash that is the same. This may not be an issue but I would be more comfortable not accidentally comparing hash from two different hash algorithm. Due to that I would prefer some approach where the hash algo as well as the fingerprint was returned and be nice to support multiple hash algos. |
There can only be one fingerprint and algorithm per certificate. Section 5.2.1 of JSEP states: "the digest algorithm used for the fingerprint MUST match that used in the certificate signature." |
That's a terrible requirement, for the reasons @fluffy outlined. See https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-05 and rtcweb-wg/jsep#305 |
The requirement that "the digest algorithm used for the fingerprint MUST match that used in the certificate signature" was misguided even according to its author. There is no relationship between certificate signature and fingerprint hash. Furthermore, RFC 4572 was specifically updated to enable multiple fingerprints per certificate. |
I think we need to have the IETF resolve the question of how security of fingerprints for certs works then we can easily make this API work for whatever the answer is. |
@rshpount RFC 4572 Update does allow for multiple fingerprints per certificate: However, JSEP only references RFC 4572, not the update. |
If it's possible to generate a fingerprint with any algorithm, should we have a fingerprint() function that takes an algorithm as a parameter? I think this is in "waiting for IETF" state. |
@alvestrand As I understand it, JSEP will be updated to reference RFC 4572 Update (which allows multiple fingerprints). |
Update to allow multiple fingerprints
Two more problems:
|
Fix Travis breakage
|
I would strongly prefer that it be async because otherwise I have to always have a fingerprint available, which is more complicated to manage because there are many ways in which an RTCCertificate is instantiated. This is particularly relevant when it's persisted (to indexedDB for example) where it becomes much harder to manage, particularly if you want to change your opinion about the hash function. |
Fix for Issue #720