Realm Crossover for PKIX Certificates

Certificates bind a user identity to a public key, under approval of a Certificate Authority (CA). Validation of certificates involves chasing a hierarchy of digital signatures until a root CA, and may additionally involve validation of intermediate CAs and/or root CA. DANE supports a mechanism to express validation constraints on certificates, including CA certificates, as part of DNS and under DNSSEC protection. This means that the technical hierarchy of DNS is used to express trust in the certificate chain. Depending on the purpose at hand, this may be interpreted as ultimate trust or part of a larger trust evaluation scheme. Clients usually identify themselves as users of a domain name, as domain names are the start of authority for online identity for individuals and organisations. The user identity is a naming scope underneath the domain, so user identity assignment is the prerogative that comes with a domain name. We express that by assuming that a domain has a Registration Authority (RA) to validate user requests for certificates. In many scenarios, the userid and domain name suffice as a form of identity. In others, additional details matter and would need additional verification; for instance, when an organisation name or a personal name is mentioned. We suggest two uses of DANE with client certificates to support these two use cases. The purpose is to support Realm Crossover for Certificates; that is, a setup where identity claims in one realm can be used in another realm, even when no prior relationships exist as a trust basis. Realm crossover for Certificates is part of a series of protocol enhancements, as overviewed in . Among the potential use cases are a global identity scheme for general communication and group participation, establishment of encryption keys, all with identity control under individually owned domains.

In the PKIX model the role of a Registration Authority (RA) is one to which the CA delegates some operational responsibilities. This specification introduces an RA underneath a domain, with access to the user database and can validate their identity. In addition, it is setup to prove to the CA that it may issue certificates. The CA may be an external entity, or it may also be local to the domain. If it is local, a combination of RA and CA operations is possible. This would work for the Profile for Users of Domains , but it may be insufficient for the Profile for Additional Attributes . When the RA needs to prove to the CA that it acts on behalf of the domain, ACME can be used. ACME also contains a good chain of identifiers that assure that any proof is specific to an unloaded certificate request. Being domain-centric, the domain RA could be granted the unique right to update the _acme-challenge label underneath the domain for the dns-01 challenge. Having validated a request before considering the request, the domain RA is in a perfect position to know what to add and what not to add. Note that this centralised use of dns-01 does not preclude the use of ACME's more dispersed http-01 challenge mechanism; but the certificates issued in that way would still use the intended identity. Where the use of other challenge methods is a concern, a domain could express this in centrally controlled DANE records for root or intermediate CA certificates that only use the dns-01 challenge.

In many online scenarios it suffices to know someone by their userid and domain name, such as "john@example.com". Certificates holding an email address provide more semantics than mere identity, namely a relation to a communication facility, and on the other end there are common name attributes, which may look like a host name but have no semantics of that kind attached. The most accurate solution would be to have a pure domain name and a user identity. This information is the prerogative of the domain whose name is used, and structures exist to deliver trust in these elements without external complications.

The "uid" or "userid" attribute [Section 2.39 of ] is intended for user identities, such as "john" in the example above. Its contents are a non-empty sequence of UTF-8 encoded UCS characters, which is almost the same as Unicode. This is a good format for expressing user identities. The "dc" or "domainComponent" attribute [Section 2.4 of ] is intended for DNS labels, and a sequence of these attribute in immediate succession can be used to describe a domain name as it is represented in DNS. Note that this notation allows A-labels for IDN2008 but not the U-labels that should be rendered to users. This profile interprets attributes in the Subject of a Certificate [Section 4.1.2.6 of ]. The general order of the Subject is from low to high in the authoritative hierarchy. This means that one "uid" value must precede two or more "dc" values. All "dc" values must occur in immediate succession and in the same order as the DNS labels that they represent occur in the domain name. It is possible to have other attributes before the "uid", between the "uid" and first "dc" and after the last "dc" attribute. This profile ignores such attributes, and assigns no trust to them. It is quite possible that other profiles apply in addition to this one, in which case these extra attributes may be trusted from that perspective. It is also possible that applications recognise the input as mere hints to construct a pleasant conversation, though without any legal or security implications. Examples of acceptable Subjects under this profile are:

Examples of rejected Subjects under this profile are:

Validation are the checks that parties run on a certificate request. This involves a few attributes: The request-originator is the client who submitted the certificate request. The request-signer is the CA that is destined to sign the certificate request. The request-key is the public key provided in the SubjectPublicKey field. The request-user is retrieved from the "uid" attribute in the Subject. This takes the form of a UTF-8 string. The request-domain is constructed from the "dc" sequence, by concatenating them in their order of appearance in the Subject, separated by a dot. The values in "dc" attributes may be A-labels when IDN2008 is applied; this means that the request-domain follows the customary DNS notation, but has no user-friendly form yet. The RA is sent a certificate request, and validates the following: The Subject attributes follow the description of . The Subject either does not fall under an LDAP service, or its object exists and represents the request-originator. The request-user is approved as a user under request-domain. The request-user falls under the control of the request-originator. The request-domain has a SOA record with DNSSEC protection. The request-key is controlled by the request-originator. The request-signer is mentioned for Client DANE in the request-domain. The request-signer is trusted to validate the request-domain. The request-signer is trusted to retain the values of the "uid" and "dc" attributes. When this is assured, the RA forwards the certificate request to the request-signer, and expects to assert that this particular request originated from the request-domain. The request-signer is sent a certificate request, and validates the following: The Subject attributes follow the description of . The request-domain RA originated this particular request and approved it. The request-key is controlled by the request-originator. When this is assured, the request-signer removes any attributes that it disapproves of, but never "uid" and "dc", and turns the certificate request into a signed certificate. It then returns that certificate to the request-domain's RA. The request-originator receives the signed certificate from the RA, and may validate the following: The Subject attributes follow the description of . The request-user, request-domain and request-key match the original request. The request-signer would normally be the one that was requested. The request-originator can now install the certificate and start using it towards a party that will hopefully trust its "uid" and "dc" attributes.

Trust in a certificate is the vital step of accepting the identity of an unknown party, in the case of this profile the identity of "uid" and "dc" attributes in the certificate Subject. These attributes should adhere to the same constraints as for validation and on top of that, they must be confirmend under Client DANE. User identities in DNS do not scale well. They are often considered a privacy problem, and cache delays make user management slow and inconsistent. Client DANE offers a better option, by mentioning a CA that signs for a domain's client certificates. The following steps are taken to evaluate trust in a certificate: The trust-user is retrieved from the "uid" attribute in the Subject. The trust-domain is constructed from the "dc" sequence, by concatenateing them in their order of appearance in the Subject, separated by a dot. For Client DANE, lookup TLSA records under TODO.[trust-domain] under the requirement that DNSSEC validates the TLSA records. Take note of any intermediate CA certificates in the TLSA records to validate the certificate. Validate the certificate under a root CA certificate from the TLSA records. After validation, the trust-user can be delivered as the certificate owner's user identity; the corresponding domain is formed like the trust-domain, except that A-labels are mapped to U-labels. TODO: role of intermediates: AND-or-OR requirements? Certificate attributes beyond "uid" and "dc" cannot be trusted; they may however provide hints for less formal uses, such as interfacing. When a Subject that ends in a sequence of "dc" attributes has a direct mapping to domain-bound LDAP service , so more structured information for the client may be found there. These attributes are likely to be more dynamic than anything in the certificate; it may be searched, and incorporate access control to implement varying attribute visibility for varying requesters. Although it may be convenient to avoid lookups of DANE records, a well-known CA adds little value for this automated validation. In fact, it adds an extra link in the chain of trust, in the form of a widely shared root key and delays in the validation. If only these automation-friendly attributes are required, then it more secure to rely on DANE, possibly combined with DANE stapling and trust a domain's own CA under strict DNSSEC assurance.

Hosts are often used to run services for a domain name. They are considered to either match the domain or one label below that. A certificate may be applicable to multiple hosts.

An old trick was to encode a host name in a "cn" or "commonName" attribute, but a modern and semantically more accurate approach is to use dNSName attributes in subjectAltName extensions [Section 4.2.1.6 of ]. This habit has the additional benefit that it can represent multiple host names in one certificate. The "cn" attribute is no longer needed, and need not be supported; we may however use "dc" attributes instead to represent the canonical host name. Hosts with a certificate tend to run services. When they do, they publish those on a port for a particular service. These values can be represented with attributes from the NIS scheme , namely "ipServicePort" (with values like "443") and "ipServiceProtocol" (with values like "tcp"). An additional "cn" (with values like "https") names the service on this protocol port, as standardised in IANA's Service Name and Transport Protocol Port Number Registry. Relative Distinguished Names combine these values in a SET, as in "ipServicePort=443+ipServiceProtocol=tcp+cn=https", which represents TCP port 443 for the HTTPS service. Adding more ports and/or protocols creates more combinations, and each combination of port and protocol is assumed to exist and run the indicated service. These RDNs can into the subjectAltName as a directoryName, alongside the dNSName values for virtual hostnames. Hosts never carry "uid" attributes, neither in their Subject nor in a subjectAltName value. TODO: Other attributes?

The following values are retrieved from the certificate request: The request-signer is the CA that is destined to sign the certificate request. The request-key is the public key provided in the SubjectPublicKey field. The request-host is constructed from the "dc" sequence, by concatenating them in their order of appearance in the Subject, separated by a dot. The values in "dc" attributes may be A-labels when IDN2008 is applied; this means that the request-domain follows the customary DNS notation, but has no user-friendly form yet. The request-domain is constructed like the request-host, but it does not use the first "dc" attribute in the Subject. The request-virtuals are the values in the subjectAltName extension tagged as dNSName. The request-ports are the values in the subjectAltName extension tagged as directoryName. The RA processes a certificate request by preparing for validation by the request-signer. This may involve adding DANE records that will be required. When done, the request is forwarded to the request-signer. TODO: Check that requester represents the host. How? The request-signer processes a certificate request by validating the following: The request-domain must have a SOA record, secured with DNSSEC. The request-host must not have a SOA record, as confirmed with DNSSEC. Every element in the request-ports must be a single RDN, whose SET contains at least one "ipServicePort" element and at least one "ipServiceProtocol", one "cn" element and no other attribute types. Within each such RDN, all possible combinations of an "ipServicePort" and an "ipServiceProtocol" are considered and subsequently combined with every element in request-virtuals. This leads to tuples of a protocol, port and DNS-name. Every tuple of a protocol, port and DNS-name is used to lookup a TLSA record. One of the records found must represent the request-key as a DANE public key. The "cn" element is not conidered, because the protocol is not being run.

When a certificate is found while accessing a service on a host, it can be used to build trust. The information stored in DANE suffices to validate the relation of the connected service host with the domain, and in situation where this suffices there should be no further need to validate the certificate based on an external CA. When depending on other attributes than "dNSName" and "ipServicePort+ipServiceProtocol+cn" this is usually desirable. Trust involves the following steps: Assure that the host name sent as SNI to the TLS service occurs in the certificate's subjectAltName as a dNSName value. Assure that the port and protocol appear in one directoryName, in one RDN, as "cn" with "ipServicePort" and "ipServiceProtocol", without regards for extra values for these attributes. Use DANE to lookup the host name, service protocol and service port and find a TLSA record that approves the TLS-sent certificate. Although it may be convenient to avoid lookups of DANE records, a well-known CA adds little value for this automated validation. In fact, it adds an extra link in the chain of trust, in the form of a widely shared root key and delays in the validation. If only these automation-friendly attributes are required, then it more secure to rely on DANE, possibly combined with DANE stapling and trust a domain's own CA under strict DNSSEC assurance. This profile is a little more specific than customary; the service protocol and service port are not normally verified, but it allowd for strong separation for service providers that may come together in one domain but be hosted by different parties who function at different security levels. Their privacy levels or jurisdictions may also differ, which is a strong indication that they should not be permitted to overtake each other's traffic, just to be able to implement legislation.

When the "uid" and "dc" fields provide insufficient trusted information, then an external authority may help to validate more information. This is usually confirmed through an external CA. Examples include probing the user at an email addresses or URL. More human attributes that may involve manual validation include the COSINE attributes . These additional attributes are not included in the Profile for Users of Domains but they can be waved there due to the root CA which is validated through DNSSEC and DANE only. Clearly, the validation path is of a technical nature and restrictions apply. More classical root CAs tend to be well-known; they are listed and securely managed as part of an operating system or software distribution. The additional validation that this brings implies trust in additional attributes. Indeed, such CAs would not keep attributes that they are not comfortable with. A solution halfway is a federation of organisations, where the members hold certificates that are ultimately signed through the federation's CA. This is another case of external CA and considered well-known, but only to the federation (and any parties that choose to also trust it). This model is not as open because the CA is not installed as part of operating system or other software. It is perfect for federation-internal security, but not outside that realm. TODO: Get concrete. TODO: Maybe add a new CA signature and extend the uid=,dc=,dc= form.

CA must check the submitting RA to be responsible for the domain being claimed. CA must check dealing with an RA and not an arbitrary user under a domain.