Internet DRAFT - draft-vanrein-cert-xover
draft-vanrein-cert-xover
Network Working Group R. Van Rein
Internet-Draft InternetWide.org
Intended status: Informational April 4, 2021
Expires: October 6, 2021
Realm Crossover for PKIX Certificates
draft-vanrein-cert-xover-00
Abstract
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.
Status of This Memo
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 October 6, 2021.
Copyright Notice
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
Van Rein Expires October 6, 2021 [Page 1]
Internet-Draft Cert Xover April 2021
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Domain Registration Authorities . . . . . . . . . . . . . . . 3
3. Profile for Users of Domains . . . . . . . . . . . . . . . . 3
3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Profile for Hosts under Domains . . . . . . . . . . . . . . . 8
4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Validation . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Profiles for Additional Attributes . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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
Van Rein Expires October 6, 2021 [Page 2]
Internet-Draft Cert Xover April 2021
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.
2. Domain Registration Authorities
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.
3. Profile for Users of Domains
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
Van Rein Expires October 6, 2021 [Page 3]
Internet-Draft Cert Xover April 2021
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.
3.1. Attributes
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
Van Rein Expires October 6, 2021 [Page 4]
Internet-Draft Cert Xover April 2021
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
3.2. Validation
Validation are the checks that parties run on a certificate request.
This involves a few attributes:
o The request-originator is the client who submitted the certificate
request.
o The request-signer is the CA that is destined to sign the
certificate request.
o The request-key is the public key provided in the SubjectPublicKey
field.
o The request-user is retrieved from the "uid" attribute in the
Subject. This takes the form of a UTF-8 string.
o 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:
o The Subject attributes follow the description of Section 3.1.
o The Subject either does not fall under an LDAP service, or its
object exists and represents the request-originator.
o The request-user is approved as a user under request-domain.
o The request-user falls under the control of the request-
originator.
o The request-domain has a SOA record with DNSSEC protection.
o The request-key is controlled by the request-originator.
Van Rein Expires October 6, 2021 [Page 5]
Internet-Draft Cert Xover April 2021
o The request-signer is mentioned for Client DANE in the request-
domain.
o The request-signer is trusted to validate the request-domain.
o 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:
o The Subject attributes follow the description of Section 3.1.
o The request-domain RA originated this particular request and
approved it.
o 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:
o The Subject attributes follow the description of Section 3.1.
o The request-user, request-domain and request-key match the
original request.
o 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.
3.3. Trust
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.
Van Rein Expires October 6, 2021 [Page 6]
Internet-Draft Cert Xover April 2021
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:
o The trust-user is retrieved from the "uid" attribute in the
Subject.
o The trust-domain is constructed from the "dc" sequence, by
concatenateing them in their order of appearance in the Subject,
separated by a dot.
o For Client DANE, lookup TLSA records under TODO.[trust-domain]
under the requirement that DNSSEC validates the TLSA records.
o Take note of any intermediate CA certificates in the TLSA records
to validate the certificate.
o 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 [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.
Van Rein Expires October 6, 2021 [Page 7]
Internet-Draft Cert Xover April 2021
4. Profile for Hosts under Domains
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.
4.1. Attributes
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?
4.2. Validation
The following values are retrieved from the certificate request:
o The request-signer is the CA that is destined to sign the
certificate request.
o The request-key is the public key provided in the SubjectPublicKey
field.
o The request-host is constructed from the "dc" sequence, by
concatenating them in their order of appearance in the Subject,
Van Rein Expires October 6, 2021 [Page 8]
Internet-Draft Cert Xover April 2021
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.
o The request-domain is constructed like the request-host, but it
does not use the first "dc" attribute in the Subject.
o The request-virtuals are the values in the subjectAltName
extension tagged as dNSName.
o 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:
o The request-domain must have a SOA record, secured with DNSSEC.
o The request-host must not have a SOA record, as confirmed with
DNSSEC.
o 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.
o 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.
4.3. Trust
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
Van Rein Expires October 6, 2021 [Page 9]
Internet-Draft Cert Xover April 2021
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:
o Assure that the host name sent as SNI to the TLS service occurs in
the certificate's subjectAltName as a dNSName value.
o 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.
o 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.
5. Profiles for Additional Attributes
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.
Van Rein Expires October 6, 2021 [Page 10]
Internet-Draft Cert Xover April 2021
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.
6. Security Considerations
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.
7. IANA Considerations
8. Normative References
[I-D.vanrein-internetwide-realm-crossover]
Rein, R., "InternetWide Identities with Realm Crossover",
draft-vanrein-internetwide-realm-crossover-00 (work in
progress), September 2020.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, DOI 10.17487/RFC2307,
March 1998, <https://www.rfc-editor.org/info/rfc2307>.
[RFC3088] Zeilenga, K., "OpenLDAP Root Service An experimental LDAP
referral service", RFC 3088, DOI 10.17487/RFC3088, April
2001, <https://www.rfc-editor.org/info/rfc3088>.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
DOI 10.17487/RFC4519, June 2006,
<https://www.rfc-editor.org/info/rfc4519>.
Van Rein Expires October 6, 2021 [Page 11]
Internet-Draft Cert Xover April 2021
[RFC4524] Zeilenga, K., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
DOI 10.17487/RFC4524, June 2006,
<https://www.rfc-editor.org/info/rfc4524>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
Appendix A. Acknowledgements
Author's Address
Rick van Rein
InternetWide.org
Haarlebrink 5
Enschede, Overijssel 7544 WP
The Netherlands
Email: rick@openfortress.nl
Van Rein Expires October 6, 2021 [Page 12]
