Thanks for the contribution, Ryan.
I already merged your two smaller changes around SNI and ALPN. I hope the WG
will comment on the larger text you provided, below.
Ryan’s mail.
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)
The proposed new text is reproduced below (improperly wrapped), again, for the
GitHub averse :)
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
