lspeed.org PKI Certification Practice Statement

Version 1.2

Updated March 2, 2018

1. Overview

This Public Key Infrastructure (PKI) deployment is used to distribute Certificates for internal use within the lspeed.org private network. The following Trust Anchors (also known as Root Certification Authorities) are covered by this Cerification Practice Statement (CPS) document:

2. Architecture, Design, and Rationale

Current best practices are adhered to as much as possible, within reason, but without getting too carried away, and remaining mindful of the fact that the ultimate purpose of the PKI is simply to meet the requirements of lspeed.org. In particular, much guidance has been taken from RFCs (especially RFC5280 [1]), and the CA/Browser Forum’s Baseline Requirements [2], although much of the latter has been ignored since there is no need to meet the requirements for issuing publicly-trusted Certificates.

2.1. CA Hierarchy

A two-tiered hierarchy is used for the Certificate Authorities (CAs), consisting of a single Root CA, and multiple Issuing CAs. A Policy CA tier would be excessive and unnecessary given the requirements. In fact one could argue that even the Issuing CAs are unnecessary, and a single CA would suffice. However the Issuing CA tier provides two useful benefits:

• It allows for changes to the Issuing CA certificate(s) to be rolled out more easily (ie without having to push out a new trusted Root CA Certificate to all clients), to take advantage of any enhancements implemented after the initial deployment of the PKI.
• Some applications may wish to be able to accept/reject certificates based on which particular Issuing CA was used, which would not be possible without an Issuing CA tier. This hierarchy is enforced at the Issuing CA level by setting the path-length basic constraint to 0 in all Issuing CA Certificates.

2.2. Cryptographic Algorithms

Modern cryptographic algorithms are used throughout the PKI thanks to an assumed lack of any need to support legacy systems, largely thanks to the very limited scope of the deployment. At present that means all certificates use Elliptic Curve Cryptography with the secp384r1 curve (aka NIST P-384), and SHA-384 for hashing.

The curve choice was based on compatibility - secp384r1 is the strongest curve supported by current versions of all major crypto libraries (as of Febrary 2018). Close contenders included:

• secp521r1 - Unfortunately this is not supported by Google Chrome.
• curve25519 - Has the advantage of not being associated with the NSA, but it only provides a security level of around 128-bits (roughly equivalent to secp256r1).
• curve448 - This has a security level of around 224-bits (roughly halfway between the strength of secp384r1 and secp521r1), and is not associated with the NSA, but has minimal support amongst crypto libraries at the moment.

The choice of SHA-384 as the hash algorithm was made for similar reasons. Potential alternatives (and reasons why they weren’t chosen) included:

• SHA-512 - This is vulnerable to length extension attacks, whereas SHA-384 is not, although supposedly that’s not relevant for X.509 signatures. Apparently it’s also preferable to match the length of the hashing algorithm with that of the encryption algorithm when using ECDSA, making SHA-384 a better match for secp384r1. Finally there are reports that Microsoft’s cryptoapi lacks full support for SHA-512.
• SHA-512/256 - This has a greater capacity for resistance to length extension attacks than SHA-384 (though it’s unclear how important that is), but has a lower security strength, and less widespread support.
• SHA3 variants - Very limited support (but supposedly coming in TLS 1.3).

If a use-case is encountered later on which lacks support for the chosen algorithms, options include issuing individual Certificates with compatible algorithms (for example RSA variants), or perhaps an additional Issuing CA specifically for issuing Certificates with legacy cryptographic algorithms (potentially explicitly trusted by systems that can’t handle the ECC-based Root CA Certificate), as appropriate.

2.3. Certificate Validity Periods

he Root CA Certificate’s expiration date has been deliberately chosen to be shortly before the date on which 32-bit Unix epoch timestamps overflow (2038-01-19), to minimize risk of incompatibility. Issuing CA Certificates are issued to expire not long before the Root CA’s Certificate, so that there is no need to worry about co-ordinating renewal timings with the remaining validity period of the Root. OCSP Signing Certificates have validity periods matching those of their associated CA. End-Entity Certificates have varying validity periods, depending on the use-case (no longer than 10 years). End-Entity Certificates issued for testing purposes have a validity period of just 1 day (see section 3.3).

CA Certificates will not be renewed. Instead, new CAs will be created to supercede older existing CAs, when the time comes (whether due to impending expiry, or in order to move to newer cryptographic algorithms, or adjust the certificates in some other way).

Once the time comes to refresh the Root CA Certificate, if the Unix epoch overflow flow issue is no longer a concern, the next date to potentially be wary of is 2050-01-01, so a likely candidate for the next Root CA Certificate’s expiry date would be shortly before then.

2.4. Revocation Information

Revocation information is made available via both CRLs and OCSP. Delta CRLs are not used as they provide no real benefit in a such a small environment, yet they increase complexity and introduce compatibility concerns. CRLs have a validity period of 75 days, and are issued at least once a month. OCSP responses are pre-generated and similarly valid for 75 days, and re-generated at least once a month. The OCSP nonce extension is not supported (as a result of response pre-generation).

The CDP and OCSP Responder URIs use HTTP, and are highly-available (hosted by 3 different physical web servers, for which health-checking is employed). The same location is used to host Certificates for AIA purposes, and for this CPS document (additionally via HTTPS). Note that while the PKIX standard MIME types are used for OCSP (application/ocsp-response) and CRL (application/pkix-crl), the NSS-specified MIME type is used for Certificates (application/x-x509-ca-cert) due to more widespread browser support.

Given the small scale of the deployment, Certificate revocations due to potential compromise are expected to occur rarely, if ever. Combined with the fact that other manual steps can easily be taken to address compromise if it ever arises, there is little need for ultra-short validity periods for revocation information - hence the chosen timings.

2.5. Certificate Issuance Policies

Issuing CA Certificates use the standard “All Policies” identifier (2.5.29.32.0), to allow for flexibility in implementing additional Policies in the future without the need to re-issue Issuing CA Certificates. End-Entity Certificates will reference a specific Policy. The Certificate Policies extension will additionally contain a link to this document (Certification Practice Statement).

This PKI has an OID arc beneath Alex Moore’s Private Enterprise Number OID assignment from IANA. And beneath that is an arc listing Certificate Issuance Policies. Specifically, the OID is: iso (1) . org (3) . dod (6) . internet (1) . private (4) . enterprise (1) . Alex Moore (51546) . lspeed.org (1) . PKI (1) . Certificate Issuance Policies (1). At the moment only a single Certificate Issuance Policy has been defined, because realistically all certificates are issued in the same manner given the small scale of the deployment. See section 5 for a description of each Policy.

2.6. Name Constraints

Name Constraints are not applied to any Certificates. There are two main reasons for this:

• The PKIX specifications in RFC5280 say this extension must be marked critical. However many clients still don’t handle Name Constraints and thus may reject such certificates if the extension is marked critical.
• Since the scope of the PKI is limited to use within lspeed.org, there is no real need for constraints, as I am quite willing to unconditionally trust all of the certificates that I have issued.

For reference, it is interesting to note that the CA/B requirements state that Name Constraints are required for public Issuing CA Certificates which are Technically Constrained (see section 2.7) and list the id-kp-serverAuth EKU. They additionally suggest that it is acceptable to mark the extension as non-critical, ignoring RFC5280 in that regard.

2.7. Technical Constraints

In theory it might be nice to use Technical Constraints to restrict which EKUs can be present in Certificates issued by each Issuing CA. However in practice this limits flexibility… It is extremely difficult to predict in advance all the EKUs that might ever be required for a given Issuing CA’s issued Certificates. The use of Technical Constraints would mean that a failure to predict EKU requirements translates into a need to re-issue Issuing CA Certificates whenever a previously unforeseen EKU is required. Besides, an initial attempt to predict required EKUs suggested there would be a high degree of overlap between the different Issuing CAs, meaning any such Technical Constraints would provide little value anyway. Thus Technical Constraints are not used within the PKI at all.

2.8. Policy Constraints

Policy Constraints are not used, as they are only really relevant in environments employing cross-certified CAs to extend trust across multiple PKIs, which is unlikely to ever arise here.

2.9. Naming Schemes

The Subject field in all Certificates will contain an org-style DN, consisting of a single CN attribute, followed by O=lspeed,C=GB. Other more specific location identifiers are omitted so that the values remain valid regardless of any future physical relocation to a different address. The CN attribute will be treated primarily as a descriptive unique identifier for the End-Entity, rather than containing one of the subject alternative name values. As such, the Subject DN will bear no resemblance to the End-Entity’s LDAP DN (if one exists).

In the specific case of CA Certificates, the CN will indicate whether it is a Root CA or an Issuing CA, and will end with a unique identifier in the form of a letter and a number, indicating the type of Certificates issued by the CA and the version number (the number is incremented each time a new CA Certificate is issued for a CA bearing the given letter). For example “R” denotes a Root CA, and “R1” is the initial Root CA. The second Root CA Certificate to be issued will be “R2”, and so on. Letter codes for each type of CA are listed in section 3 below.

3. Certificate Authorities

The different categories of CA are listed below, along with a brief description of the types of Certificates they will issue:

3.1. R - Root

This is the Root CA (ie Trust Anchor). It issues Certificates for the Issuing CAs.

3.2. S - Services

The Services CA issues Certificates to daemons of various kinds, for example: web servers, mail servers, LDAP servers, etc. These certificates facilitate TLS, and authenticate the server to the client.

3.3. T - Testing

This CA is intended to facilitate testing of Certificate Profiles. As such, it is possible that it will issue some Certificates which do not conform to the Certificate Profiles documented in section 4. However all Certificates issued by this CA will have a validity period of just 1 day, so they can largely be ignored. While it might be preferable to avoid using the production PKI for experimentation, it would not be trivial to setup a dedicated PKI for testing purposes, not least because in order for it to be a valid test, the PKI needs to be trusted by the relevant systems, at which point the distinction between a test PKI and the production PKI begins to fade anyway.

3.4. U - Users

This CA issues Certificates identifying End Users, which typically means real people, but could include some service accounts which need to authenticate themselves as a client to other services.

3.5. V - VPN Endpoints

Certificates used for VPN authentication are issued by a dedicated CA, to simpify the trust configuration on the VPN endpoints (they can explicitly trust this Issuing CA, rather than the Root CA). Both VPN server and VPN client Certificates are covered, for VPN deployments which have such a distinction.

4. Certificate Profiles

This section details the extensions used in various different types of Certificate, and also indicates which type of CA issues them (where applicable).

4.1. Root CA Certificate

• Validity: Until 2038-01-18
• Basic Constraints: Critical, CA: true
• Key Usage: Critical, Certificate Signing, CRL Signing

4.2. OCSP Responder Ceritificate

• Validity: Same as validity period of associated CA
• Basic Constraints: Critical, CA: false
• Key Usage: Critical, Digital Signature
• Certificate Policies: Standard Certificate Issuance Policy
• Extended Key Usage: Critical, OCSP Signing
• No Check: Ignored

4.3. Issuing CA Certificate (R)

• Validity: Until 2037-12-31
• Basic Constraints: Critical, CA: true, Path length: 0
• Key Usage: Critical, Certificate Signing, CRL Signing
• Certificate Policies: All Issuance Policies

4.4. Web Server Certificate (S)

• Validity: 10 years
• Basic Constraints: Critical, CA: false
• Key Usage: Critical, Digital Signature, Key Encipherment
• Certificate Policies: Standard Certificate Issuance Policy
• Extended Key Usage: Server Authentication, Client Authentication
• Subject Alternative Name: DNS

5. Certificate Issuance Policies

As mentioned earlier, just a single Certificate Issuance Policy has been defined, detailed below. If any others are added at a later date, they will be added here as well.

5.1. Standard Certificate Issuance Policy (1.3.6.1.4.1.51546.1.1.1.1)

Certificates are considered to have been issued in accordance with this policy if I deem it reasonable to do so, purely in the interests of lspeed.org.

6. External References

1. https://www.ietf.org/rfc/rfc5280.txt
2. https://cabforum.org/baseline-requirements-documents/