Higher Education PKI-Lite
Certification Authority Certificate Profile

Document: hepki-tag-pkilite-root-profile-7.html
Editor: James Jokl
Date: April 4, 2005
Comments to: hepki-tag@internet2.edu

Reference: Implementors should reference RFC-3280 and RFC-2459 for additional details.

This profile is intended for use both for self-signed root institutional certificates and for intermediate CA certificates for cases where the campus CA is part of a hierarchy such as CREN.

HE-PKI-Lite CA Certificate Profile Summary Table

Field Name Value Example Specified Explanation

Version 0x2 0x2 Y Version 3 certificates are specified by the PKI-lite profile

Serial Number a unique integer 334 Y An integer that is unique among all certificates signed by the CA that signed this certificate.

Signature Algorithm SHA1/RSA N We recommend the use of SHA1/RSA. You are likely to experience interoperability problems if you choose DSA.

Issuer DN Either (a) the same as the Subject name if this is self-signed, or (b) the Subject name in the signing CA's authority cert. Y HEPKI-TAG recommends that you keep this field simple to avoid problems with some software. If this certificate is a self-signed root certificate, this field will be identical to your Subject field. If this certificate is an intermediate certificate, this field will be specified by the signing CA. The use of domain component naming as per the HEPKI-TAG dc naming recommendation is optional. Notes for PKI implementors

Validity Time The validity period must be greater than the period of any certificates signed by this certificate or below this certificate in the chain. Y Notes for PKI implementors

Subject DN cn=your pki's name, E=pkimaster@youruniversity.edu, o=YourUniversity, c=US, dc=youruniversity, dc=edu Y If this is a self-signed root certificate, this field must be identical to to the Issuer field. If this is a campus intermediate certificate, we recommend that you keep this field as simple as possible. The use of domain component naming as per the HEPKI-TAG dc naming recommendation is optional.

Public Key N Recommend a minimim of a 2048 bit key

Certificate Extensions

Key Usage Certificate Signing , Off-line CRL Signing , CRL Signing(06) N While not specified, we recommend the use of the specified attributes and that this extension be marked critical.

Basic Constraints CA=true Subject Type = CA Y We recommend that you omit the Path Length attribute. This extension must be present in CA certificates and must be marked critical as per RFC-3280 and RFC-2459.

CRL Distribution Points N If the certificate specifies a CRL location, the CA must produce CRLs. Furthermore, the CA must update the CRL as promised in the CRL's next issue field. Notes for PKI implementors

Certificate Policy HE PKI-Lite Policy OID N We recommend that you omit the HEPKI PKI-Lite policy OID. If you are willing to take some risk about how future applications may interpret this field you may choose to include the HE PKI-Lite policy OID.

Subject Alt Name E= email:pkimaster@youruniversity.edu Y The Email identifier should be in both the Subject and SubjectAlt name fields.

CPS Pointer URI Pointer to CA's Certification Practices Statement Y The publication of a Certification Practices Statement is required by the HE PKI-Lite Policy.

Authority Key Identifier KeyID See recommendation in RFC-3280 Y Use of this extension is required by RFC-3280 but only encouraged by PKI-Lite. We strongly encourage that only the keyIdentifier field be populated in the Authority Key Identifier extension. Do not mark this extension critical. See Notes for PKI implementors for more details.

Subject Key Identifier KeyID See recommendation in RFC-3280 Y Use of this extension is required by RFC-3280 but only encouraged by PKI-Lite. We strongly encourage that only the keyIdentifier field be populated in the Authority Key Identifier extension. Do not mark this extension critical. See Notes for PKI implementors for more details.

Other fields ? CAs may include other elements in certificated as needed. HEPKI-TAG recommends that certificates be kept as simple as possible to maximize interoperability.

CA Certificate Profile Summary Table Legend

Specified column

Y	The profile specifies the use of this field as documented.
N	The profile does not specify the usage but may recommend a way to use the field.
?	Still undecided.
italics	Example of an optional element.

HE PKI-Lite Certificate Profile Implementor Notes

Issuer Field
Some certification authorities have found it beneficial to place a version number into the CN of the Issuer field and increment this number with major changes to the CA.
Certificate Validity Period
The validity period of a HE-PKI-Lite CA certificate is recommended to be at least twice as long as the End Entity (EE) certificates being issued by the CA. This is necessary to ensure that the CA certificate will be valid for the entire lifespan of an EE certificate issued on the last day that the private key associated with the CA certificate is used to sign EE certificates.
A significantly longer validity period for the CA certificate is acceptable. A longer validity period may be useful if the CA certificate will also be used for other services on campus, such as signing longer-lived server certificates.
Unless you have carefully thought through the implications and know better, we strongly recommed that you set a validity period of at least ten years.
CRL Distribution Points
The HE-PKI-Lite profile does not require the use of revocation or CRLs. Our advice is to use CRLs to revoke certificates when the user's private key may have been compromised but to not use CRLs for other purposes. For example, we recommend the use of directory-based authorization after PKI-based authentication to handle cases such as when a student is no longer at the university or when a faculty member retires.
The HE-PKI-Lite Policy requires that CAs listing CRL Distribution Points implement the following practices:
- Certificates are actually revoked as needed.
- New CRLs are issued by the specified Next Issue date.
- The CA's revocation practice is documented in the CA's Certicication Practices Statement (CPS).
Authority Key Identifier
The Authority Key Identifier is used by path validation software to help identify the next certificate up in a certificate chain. This extension can contain a keyIdentifier which is typically a hash based on the authority certificate's public key and/or fields containing the authority certificate's Subject Name and Serial Number.
Including the Subject Name and Serial Number information in a simple hierarchical CA is fine and does not cause problems. However, in a PKI Bridge environment its almost impossible to coordinate the serial numbers in the cross certificates to match those in the subsidiary certificates and thus bridge path validation fails. For this reason we strongly recommend that only the keyID be included in Authority Key Identifier. The appropriate OpenSSL configuration file line is:
authorityKeyIdentifier=keyid:always
We recommend that the Authority Key Identifier be included in all certificates issued in a PKI-Lite hierarchy. The extension is not needed in a self-signed root certificate but will not cause problems if present in a root certificate.
Subject Key Identifier
The Subject Key Identifier is used by path validation software by helping to identify certificates that contain a particular public key. The appropriate OpenSSL configuration file line is:
subjectKeyIdentifier=hash:always
We recommend that the Subject Key Identifier be included in all certificates issued in a PKI-Lite hierarchy. PKIX requires this extension in all CA certificates.

Higher Education PKI-Lite Certification Authority Certificate Profile

CA Certificate Profile Summary Table Legend

HE PKI-Lite Certificate Profile Implementor Notes

Higher Education PKI-Lite
Certification Authority Certificate Profile