search

w3c / openscreenprotocol

Open Screen Protocol
https://www.w3.org/TR/openscreenprotocol/
Other
89 stars 22 forks source link

Do not use Distinguished Name to convey protocol details #278

Open sleevi opened 3 years ago

sleevi commented 3 years ago

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: https://github.com/w3c/openscreenprotocol/blob/5488c7b7cce9c9c64ba97348a8deb0c6c50eb9bb/index.bs#L393-L406

  1. 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

  2. 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.

markafoltz commented 2 years ago

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

_openscreen.<Instance Name>._openscreen._udp_.local

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.