Higher Education PKI-Lite
End Entity Certificate Profile

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

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

HE-PKI-Lite 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 issued by your CA.

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 Identical to the CA's Subject field. Typically:
cn=your pki's name, o=YourUniversity, c=US, dc=youruniversity, dc=edu Y This field is defined by the Certification Authority that signs this End Entity certificate. HEPKI-TAG recommends that you keep this field simple when you design your CA to avoid problems with some software. The use of domain component naming as per the HEPKI-TAG dc naming recommendation is optional. Notes for PKI implementors

Validity Time Not valid before: date
Not valid after: date plus 12 to 13 months Y Notes for PKI implementors

Subject DN E=jas@youruniversity.edu, cn=Joe A. Smith, ou=your PKI's name, o=YourUniversity, c=US, dc=youruniversity, dc=edu Y HEPKI-TAG recommends that you keep this field simple to avoid problems with some software. The use of domain component naming as per the HEPKI-TAG dc naming recommendation is optional. Notes for PKI implementors

Public Key N Recommend a minimim of a 1024 bit key. Notes for PKI implementors

Certificate Extensions

Key Usage N Key usage is not specified by the PKI-lite profile. We suggest either skipping this extension or specifying Digital Signature and Key Encipherment. If the extension is used in your certificates, it should be marked critical as per RFC 2459 and RFC 3280

Basic Constraints CA=false CA=false Y HEPKI-TAG recommends that this field be present in End Entity certificates. If this field exists in the certificate, it must be marked critical as per RFC 2459 and RFC 3280. Notes for PKI implementors

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

Certification 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. If this field is included, the meaning of the OID should be described in the Certification Policy and Practices statement.

Subject Alt Name E= email:jas@youruniversity.edu Y The Email identifier should be in both the Subject and SubjectAlt name field if S/MIME is a planned application.

Other Name
Principal Name unique-identifier@youruniversity.edu N Microsoft PKI-enabled applications (e.g., EAP-TLS wireless authentication) work better if this extension is present in end user certificates. Notes for PKI implementors
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. This pointer should point to an on-line copy of your Certification Policy and Certification Practices Statement. Notes for PKI implementors

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. 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.

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
Since the Issuer field is actually specified by the CA signing the certificate, the notes here are really advice for the CA implementation.
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 certificate is recommended to be no longer than 13 months. Validity periods on the order of hours may be common for some CAs. This validity period was chosen to enable some low risk applications where authorization is implied given successful authentication (e.g. access to some site licensed library materials). However, as a general rule, authentication and authorization should be distinct processes whenever possible. Some institutions may choose to have student certificates expire during a rolling period of time in September. This will ensure that students are back on campus to ease the support workload and minimize help desk traffic by spreading certificate expirations across the month.
Subject Field
Implementors should consider planned applications before deciding on the naming convention used in Subject field of the certificates they issue. If S/MIME is a planned application, real user names with email addresses included in both the Subject and Subject Alternative Name are specified. If S/MIME is not a planned application, implementors may prefer to use a pseudo-anonymous identifier in the Subject field to enhance privacy. Some mechanism for campus application developers to map pseudo-anonymous identifiers into campus computing ids is likely to be needed if this mechanism is chosen. CA's issuing certificates containing real names and email addresses should ensure that their users understand that by using their certificate they are making this information available to the remote server. An analogy of showing your ID card to the remote server may be a useful way to explain the concept to your users.
The HE-PKI-Lite Policy requires the following attributes for a subject name:
- Subject names must uniquely map to an individual while the certificate is valid.
- Subject names should map uniquely to the same individual in perpetuity.
- The CA must publish its practice on the uniqueness of Subject names.
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).
Public Key Length
There may be circumstances where key lengths shorter than 1024 are reasonable and acceptable. An example may be the case of short-lived certificates that don't need to provide long-term protection for data in an environment with limited computational resources. Key lengths of less than 1024 bits are not recommended for CAs issuing certificates with validity periods of many weeks or months.
Note: some older PKI software may have problems with key lengths of greater than 512 bits.
Certificate Practices Statement Pointer
HEPKI has developed a merged Certification Policy and Certification Practices Statement document template. This document is designed so that with a few small edits a campus will have a reasonable set of policy and practices documents ready for use.
Basic Constraints
HEPKI-TAG used to recommend that certificate extensions not be marked critical to avoid potential interoperability problems with some older PKI implementations. We are now aware of some newer implementations that reject certificates that do not exactly follow the RFCs and fail to mark Basic Constraints as a critical extension.
Subject Alt Name / Other Name / Principal Name
Some Microsoft PKI-enabled applications use a Microsoft OID (1.3.6.1.4.1.311.20.2.3) in Subject Alt Name / Other Name to label a unique identifier for the Subject of an end entity certificate. In particular the Microsoft EAP-TLS wireless supplicant passes this field to the Radius server for authentication purposes. If this field is not present, the Subject CN is used and the CN by itself is not a unique identifier in many higher education PKIs. Given the large installed base of Windows-based computers, HEPKI-TAG recommends that you include this extension in your certificates. Some additional information is available on the Microsoft web site. Other vendors in the EAP-TLS space (Cisco and Funk Software) also specifically document the use of this field as documented here.
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.
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 that this extension be included in end entity certificates.

Higher Education PKI-Lite End Entity Certificate Profile

Certificate Profile Summary Table Legend

HE PKI-Lite Certificate Profile Implementor Notes

Higher Education PKI-Lite
End Entity Certificate Profile