GOpenCDR certificate policy and practice statement

1. Introduction

The GOpenCDR certificate authority issues TLS server certificates for names in GOpenCDR TLDs, and for nothing else. This document is both its certificate policy and its certification practice statement, following the outline of RFC 3647.

It is not part of the public web PKI. Browsers and operating systems do not trust it by default. A person trusts it by installing the GOpenCDR root, which the portal offers only after an explicit confirmation that says what installing it means.

Participants. The certificate authority is Gelhaus Solutions, acting as Tier 0. Subscribers are whoever obtains a certificate for a name they control, bound by the certificate subscriber agreement. Relying parties are whoever trusts the GOpenCDR root.

Usage. TLS server authentication for DNS names in GOpenCDR TLDs. Not client authentication, code signing, email protection or IP addresses.

Contact: egelhaus@ennogelhaus.de. This document changes only after public comment, and every version is kept in the document archive.

2. Publication and repositories

• The root certificate is published over HTTPS at cdr.gplatform.org, in the transparency log and in signed release packages.
• Every certificate is logged in the GOpenCDR certificate transparency log before it is used. The log is public and append-only, and nothing in it can be removed.
• Certificate revocation lists are published at the address in each certificate, renewed at least every 24 hours and within one hour of a revocation.

3. Identification and authentication

• Names. A certificate contains only DNS names in TLDs that are currently part of GOpenCDR. A wildcard name is issued only after a DNS challenge.
• Control of the name is proven through ACME (RFC 8555). Every DNS lookup made to validate a challenge is validated with DNSSEC against the GOpenCDR anchors, and an answer that does not validate fails the challenge. HTTP and TLS-ALPN challenges connect only to addresses from validated answers.
• CAA records are checked for every name, through validated lookups, and a record that does not permit the GOpenCDR certificate authority stops the issuance.
• No identity is validated. A certificate shows that its subscriber controlled the names in it when it was issued, and says nothing about who the subscriber is.

4. Certificate life cycle

• Validity. At most 45 days. Renewal is a new ACME order.
• Issuance follows validation, the CAA check and logging. The CA issues nothing outside its name constraints.
• Revocation. A subscriber revokes through ACME, with the account key or the certificate key. We revoke within 24 hours of establishing any of these: the key is compromised; the subscriber no longer controls a name, including when its registration ends or passes to somebody else; the name is withdrawn under the IANA rule or its TLD leaves GOpenCDR; the certificate was issued wrongly; the subscriber agreement has been broken; or a court or an authority orders it.
• Status is published only through revocation lists. There is no OCSP.
• A TLD that is sunset is taken out of the name constraints before its IANA delegation, so that no certificate for a name in it validates against a current root.

5. Facility, management and operational controls

• CA keys are held in HashiCorp Vault on our own hardware in Germany, reachable only over WireGuard, and never leave it.
• The root key is offline. It is held in the ceremony key store, sealed outside key ceremonies and opened only with three of five key shares, and it is used only in scripted ceremonies with at least two witnesses, whose minutes are entered in the transparency log.
• The issuing key signs inside the key store, as a non-exportable key.
• A change to the CA's configuration needs a second authorised person, who confirms with a hardware-bound passkey.
• Every issuance and every revocation is recorded in the audit log and in the certificate transparency log.

6. Technical security controls

• CA keys are ECDSA keys on P-256 or P-384. Subscriber keys may be ECDSA on P-256 or P-384, or RSA of at least 2048 bits. Subscribers generate their own keys, and we never see a private key.
• Name constraints. Every CA certificate carries a critical name constraints extension that permits only the current GOpenCDR TLDs as DNS names and excludes every IPv4 and IPv6 range. A certificate for any other name cannot validate under it, including a name in the IANA namespace.
• The root is re-issued with the same key whenever the set of TLDs changes, and the new root is published through the same three channels. A root installed earlier still permits the TLDs it named when it was issued. Relying parties should therefore install each re-issued root, and anyone can check in the transparency log that the CA has issued nothing outside the current set.
• Signers keep NTS-synchronised clocks.

7. Certificate and revocation list profiles

X.509 version 3. The names are in the subject alternative name extension, the extended key usage is server authentication only, and the certificate carries the address of its revocation list and the proof of its entry in the transparency log.

8. Review

Tier 0 reviews these practices every year. The certificate transparency log is a continuous public check on every certificate the CA has issued.

9. Legal matters

• Certificates are free.
• What we process about subscribers is described in the GOpenCDR privacy notice. The names in a certificate are public in the transparency log for good.
• No warranty is given to subscribers or relying parties, and no service level applies. For what is given away, liability is limited to intent and gross negligence (Section 521 BGB), and otherwise as the general terms of service set out.
• German law applies.