* It started off with this discussion, but clearly, it's a much broader change. It does try and reintroduce the ALPN conversation, although with a looser 2119 fit, and trying to explain the "why" of the SHOULD, in a way directly relevant to this specification, in a way that is hopefully acceptable to mitigating the concerns previously raised.
* I'm specifically proposing splitting up "Multiple Identifiers" into two discussions - "Multiple Presented Identifiers" (multiple names in certs, and concerns for server operators) and "Multiple Reference Identifiers" (multiple acceptable names to match, and concerns for client implementations) I really like your proposal. I split it off into its own pull request, https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/33. Again for this not comfortable with GitHub, here’s the new text, followed by Ryan’s comments on it. This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a certificate, which allows for a single application service to use the same certificate for multiple identifiers. This enables a single certificate to be used across multiple hostnames, such as when a client does not support the TLS SNI extension, or across multiple protocols, such as SMTP and HTTP, on a single hostname. The use of a single certificate and public/private keypair in such environments MAY facilitate cross-protocol attacks, particularly when used in differing TLS configurations. See, for example, {{ALPACA}}, {{DROWN}}. Server operators SHOULD take steps to mitigate the risk of cross-protocol attacks, such as ensuring all TLS endpoints using a given certificate support exactly the same TLS version(s) and ciphersuite(s), and SHOULD make use of the TLS ALPN extension to ensure the correct protocol is used. ## Multiple Reference Identifiers This specification describes how a client may construct multiple acceptable reference identifiers, and may match any of those reference identifiers with the set of presented identifiers. {{PKIX, Section 4.2.1.10}} describes a mechanism to allow CA certificates to be constrained in the set of presented identifiers that they may include within server certificates. However, these constraints only apply to the explicitly enumerated name forms. For example, a CA that is only name constrained for DNS-IDs is not constrained for SRV-IDs and URI-IDs, unless those name forms are also explicitly included within the name constraints extension. A client that constructs multiple reference identifiers of different types, such as both DNS-ID and SRV-IDs, as described in {#verify-reference-rules}, SHOULD take care to ensure that CAs issuing such certificates are appropriately constrained. This MAY take the form of local policy through agreement with the issuing CA, or MAY be enforced by the client requiring that if one form of presented identifier is constrained, such as a dNSName name constraint for DNS-IDs, then all other forms of acceptable reference identities are also constrained, such as requiring a uniformResourceIndicator name constraint for URI-IDs. * I understand this latter text may have some degree of controversy attached; one of the intended aspects of flexibility with nameConstraints was precisely that it allows new name forms to be introduced in the future, without requiring the reissuance of certificates. I've tried to balance that with the client behaviour, namely, that a client shouldn't construct a given reference identifier / allow a match for a given reference identifier unless it's constrained, _if_ it accepts other forms of constrained reference identifiers. * The canonical example here of the challenge is something like introducing support for SRV-IDs within browser clients, which would be a huge boon to reducing the risk of cross-protocol issues like ALPACA. However, clients cannot (safely) do this as long as there exist servers that are only constrained for dNSNames, without corresponding SRVName constraints. This tries to balance that, by suggesting the client should, when presented with such a constrained chain, only allow DNS-ID reference identifiers to match (because the indication that "some" constraint was intended). Reissuance of that intermediate, to also constrain SRVName, would provide the explicit signal to the client that it's acceptable (or not) to use SRV-ID reference identifiers. * This does not holistically integrate it (e.g. by adding a cross-reference to #verify-reference-rules to the security considerations), but is meant to see if there is objection/concern with this approach.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
