| Internet-Draft | Cert Xover | April 2021 |
| Van Rein | Expires 6 October 2021 | [Page] |
Certificates can express user attributes, but the semantics behind them, especially the validation policy, is not always clear. This specification describes how domains can use their prerogative to define user identities for a recognised domain user. This enables foreign realms to validate the identity of the domain user without with mere certificate logic.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 October 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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 [I-D.vanrein-internetwide-realm-crossover]. 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 [RFC5280] 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 Section 3, but it may be insufficient for the Profile for Additional Attributes Section 5.¶
When the RA needs to prove to the CA that it acts on behalf of the domain, ACME [RFC8555] 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 [RFC4519]] 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 [RFC4519]] 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 [RFC5890] 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 [RFC5280]]. 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:¶
uid=john,dc=example,dc=com uid=john,dc=example,dc=com,associatedDomain=example.com uid=john,ou=Users,dc=example,dc=com cn=Johann+Johannson,uid=john,dc=example,dc=com uid=john,ou=Users,dc=example,dc=com,c=se¶
Examples of rejected Subjects under this profile are:¶
dc=example,dc=com,uid=john dc=example,dc=com uid=john,dc=example uid=john,associatedDomain=example.com uid=john,uid=johann,dc=example,dc=com uid=john,dc=example,c=se,dc=com¶
Validation are the checks that parties run on a certificate request. This involves a few attributes:¶
The RA is sent a certificate request, and validates the following:¶
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:¶
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 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:¶
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 [RFC3088], 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 [RFC5280]]. 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 [RFC2307], 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 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:¶
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:¶
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 [RFC4524].¶
These additional attributes are not included in the Profile for Users of Domains Section 3 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.¶