Skip to content
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

Do not use Distinguished Name to convey protocol details #278

Open
sleevi opened this issue Apr 6, 2021 · 2 comments
Open

Do not use Distinguished Name to convey protocol details #278

sleevi opened this issue Apr 6, 2021 · 2 comments
Labels
security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.

Comments

@sleevi
Copy link

sleevi commented Apr 6, 2021

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

<tr>
<td>Issuer Name</td>
<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>

  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.

@samuelweiler samuelweiler added the security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. label May 27, 2021
@markafoltz markafoltz added the F2F label Sep 8, 2022
@markafoltz
Copy link
Contributor

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.

@markafoltz
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.
Projects
None yet
Development

No branches or pull requests

3 participants