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
The current certificate profile is incompatible with browser security requirements for verifying certificates, and uses fields known to cause interoperability issues.
Specifically, the following section demonstrates this:
<td>CN = The `model-name` from the `agent-info` message.<br/>
O = See note.<br/>
L = See note.<br/>
ST = See note.<br/>
C = See note.<br/>
</td>
</tr>
<tr>
<td>Subject Name</td>
<td>CN = `<fp>`._openscreen._udp.local<br/>
O = See note.<br/>
</td>
The commonName field is used to convey a form of "SRV-ID" (see https://tools.ietf.org/html/rfc6125 ).
As captured at https://datatracker.ietf.org/doc/draft-ietf-uta-use-san/ , the use of DNS-IDs/SRV-IDs within the commonName causes both interoperability and security issues. If this is necessary as part of client validation, then using the SRV-ID (since this is not strictly a DNS-ID, due to underscores and SRV records), it's recommended to use the SRVName as captured within RFC 4985
The issuer Distinguished Name is used to convey human-presentable language, which is counter to good practice.
Multiple issues exist with DN, leading to a host of implementation issues. For example, field length limits that apply in the context of PKIX/RFC 5280 but that do not apply in context of X.509, or character encoding issues in which the UTF8String/PrintableString SHOULD of 5280 (and MUST of 3280) are ignored in favor of bespoke not-quite-T61String or BMPString (which may be perceived as having embedded NULs).
While it's required that the Issuer have a non-empty Distinguished Name (a decision made during RFC 2459 to keep compat with the X.500 model of certificates that was largely not deployed), a better practice is simply to generate a random value.
This is particularly important when considering a user may interact with multiple devices that share the same model-name, which can create ambiguity if any attempt is made to validate the certificate beyond the fingerprint comparison, which the random (non-human-readable) value would accomplish.
The text was updated successfully, but these errors were encountered:
I see a feasible resolution for the second issue pointed out.
For the Issuer Distinguished Name, we can set the CN a random value with some human readable prefix and a hex-encoded random value appended, and omit the other relative name fields. For example:
openscreen-deadbeef74398743
This fits the requirements for an ASN.1 PrintableString.
Since all OSP certificates are new and self-issued we don't have to worry about interop with legacy string formats (BMPString, etc.)
For the first issue raised (changing the subject commonName), here is my analysis. The SRV-ID appears to be the following format:
_openscreen.<Domain Name>
Which, for agents advertising through DNS-SD, expands to
First, the format seems redundant as it includes the service name twice. Second, the <Instance Name> may change based on user input (as it is based on the display name) and may collide with other Instance Names on the LAN (there is no requirement that I am aware of for uniqueness).
For these reasons SRV-ID as-is does not look like the right choice for this application.
#332 solves the first issue raised here by creating a hostname for the agent and using that in the CN field.
The second issue is minor, as pretty much every certificate on the open Web has a human readable issuer name. However we should try to come up with something that complies with X.509 and uniquely identifies the agent, as the the certificate is inherently self-issued.
The current certificate profile is incompatible with browser security requirements for verifying certificates, and uses fields known to cause interoperability issues.
Specifically, the following section demonstrates this:
openscreenprotocol/index.bs
Lines 393 to 406 in 5488c7b
The commonName field is used to convey a form of "SRV-ID" (see https://tools.ietf.org/html/rfc6125 ).
As captured at https://datatracker.ietf.org/doc/draft-ietf-uta-use-san/ , the use of DNS-IDs/SRV-IDs within the commonName causes both interoperability and security issues. If this is necessary as part of client validation, then using the SRV-ID (since this is not strictly a DNS-ID, due to underscores and SRV records), it's recommended to use the SRVName as captured within RFC 4985
The issuer Distinguished Name is used to convey human-presentable language, which is counter to good practice.
Multiple issues exist with DN, leading to a host of implementation issues. For example, field length limits that apply in the context of PKIX/RFC 5280 but that do not apply in context of X.509, or character encoding issues in which the
UTF8String
/PrintableString
SHOULD of 5280 (and MUST of 3280) are ignored in favor of bespoke not-quite-T61String
orBMPString
(which may be perceived as having embeddedNUL
s).While it's required that the Issuer have a non-empty Distinguished Name (a decision made during RFC 2459 to keep compat with the X.500 model of certificates that was largely not deployed), a better practice is simply to generate a random value.
This is particularly important when considering a user may interact with multiple devices that share the same
model-name
, which can create ambiguity if any attempt is made to validate the certificate beyond the fingerprint comparison, which the random (non-human-readable) value would accomplish.The text was updated successfully, but these errors were encountered: