openscreenprotocol
openscreenprotocol copied to clipboard
w3c
Agent Certificate has a circular dependency on itself
The value fp is defined as: https://github.com/w3c/openscreenprotocol/blob/5488c7b7cce9c9c64ba97348a8deb0c6c50eb9bb/index.bs#L285-L291
Agent Certificate then follows, with the definition at: https://github.com/w3c/openscreenprotocol/blob/5488c7b7cce9c9c64ba97348a8deb0c6c50eb9bb/index.bs#L354-L417
The issue is that the certificate Serial Number field makes use of fp, as described at
https://github.com/w3c/openscreenprotocol/blob/5488c7b7cce9c9c64ba97348a8deb0c6c50eb9bb/index.bs#L385-L388
The problem is that fp is computed over the certificate, so one cannot compute fp apriori to include within the certificate, and any inclusion within the certificate would naturally change the derived fingerprint.
We also need to fix the certificate subject name not to refer to the certificate fingerprint.
Regarding the subject name, similarly replacing it with the serial number could look as follows:
- Advertise the serial number as a
snmDNS TXT record. - use
<sn>._openscreen._udpas the certificate Subject CommonName. - The dialing client can use the
snTXT record to construct the<sn>._openscreen._udpto use in the server_name extension.
This keeps the 1:1 relation between server name and certificate. It don't think it impacts the certificate validation based on the fingerprint. That being said, I may have missed some of the original considerations put into the current spec. If someone can validate that, I'm happy to do the writeup and send a PR for review.
It seems "Issuer Name" also has problem. According to the spec, "Issuer Name" is set as the model-name from the agent-info message. However, the model-name information is exchanged during the metadata phase which happens after the connection. Is there something wrong with my understanding?
It seems "Issuer Name" also has problem. According to the spec, "Issuer Name" is set as the model-name from the agent-info message. However, the model-name information is exchanged during the metadata phase which happens after the connection. Is there something wrong with my understanding?
My interpretation of this is that it's the model name of the agent creating the certificate itself, meaning the model name as it is also added to the agent-info message; not the model name as is received from the remote agent. Can someone confirm/deny this? If my interpretation is correct, we may want to rephrase this to avoid any confusion.
Regarding the subject name, similarly replacing it with the serial number could look as follows:
That sounds like a great approach. bakkem@, do you have the capacity to put up a proposed PR that implements that?
It seems "Issuer Name" also has problem. According to the spec, "Issuer Name" is set as the model-name from the agent-info message
This should be same as the the model-name of the agent that is generating the certificate. The text here could be clearer on this.
The entire Issuer Name field is mostly for debugging purposes as the certificates are self-signed.
Regarding the subject name, similarly replacing it with the serial number could look as follows:
That sounds like a great approach. bakkem@, do you have the capacity to put up a proposed PR that implements that?
I will start with the spec changes. Afterwards I may look at the C implementation. My Go implementation already does this as the spec was implementable otherwise 😅
I just remembered there is another precedent for this set by WebRTC's local ICE candidates:
Generate a unique mDNS hostname. The unique name MUST consist of a version 4 UUID as defined in [RFC4122], followed by ".local".
I'm not sure if the added entropy would be warranted in our case.
It seems "Issuer Name" also has problem. According to the spec, "Issuer Name" is set as the model-name from the agent-info message
This should be same as the the
model-nameof the agent that is generating the certificate. The text here could be clearer on this.The entire Issuer Name field is mostly for debugging purposes as the certificates are self-signed.
Thanks, this makes sense to me.