rfc-3739

Internet X.509 Public Key Infrastructure: Qualified Certificates Profile

S. Santesson, M. Nystrom, T. Polk
date2004-03 streamIETF areasec wgpkix statusPROPOSED STANDARD pages34 canonicalhttps://www.rfc-editor.org/rfc/rfc3739 doi10.17487/RFC3739 errataview
This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]

obsoletes

Extracted elements (33)

design-rationale §3.2.5

Biometric information is stored only as a hash in the biometricInfo extension, not the actual biometric template itself, to enable authentication of biometric information without embedding potentially large and sensitive raw data in the certificate.

pkix, privacy

design-rationale §3.2.2

The dateOfBirth is encoded at noon GMT (120000Z) to prevent accidental date changes caused by time zone adjustments when interpreting a GeneralizedTime value across different locales. Applications are expected to strip the time component and display only the date.

pkix

design-rationale §2

The profile is intentionally not limited to Qualified Certificates as defined by the EU Electronic Signature Directive; it is broadly applicable to any high-assurance identity certificate for natural persons, with local legal qualification being out of scope.

pkix

design-rationale §3.2.6

The QCStatements extension does not allow mixing critical and non-critical statements; either all statements in the extension are critical or all are non-critical. This simplifies criticality semantics so relying parties need not evaluate each statement individually for criticality.

pkix

interoperability-note §3.1.2

Many client implementations presuppose the presence of the commonName attribute in the subject field and use it to display the subject's name, regardless of present givenName, surname, or pseudonym values. Implementations wishing broad client compatibility should include commonName.

pkix

interoperability-note §3.1.2

Many X.500 implementations require countryName in the DIT. In cases where the subject name specifies a public X.500 directory entry, countryName SHOULD always be present in the subject field.

pkix, ldap

interoperability-note §3.2.6.1

The id-qcs-pkixQCSyntax-v1 OID is retained for backwards compatibility to identify certificates issued under the obsoleted RFC 3039 (Version 1). New certificates conforming to this profile (RFC 3739, Version 2) MUST use id-qcs-pkixQCSyntax-v2 and MUST NOT include the v1 statement.

pkix

normative-requirement §3.2.5 MUST

If a sourceDataUri is included in the biometricInfo extension, it MUST use the HTTP scheme (http://) or the HTTPS scheme (https://). The biometricInfo extension MUST NOT be marked critical.

pkix, http

normative-requirement §3.2.6.1 REQUIRED

If a value of type SemanticsInformation is present in a QCStatement with statementID set to id-qcs-pkixQCSyntax-v1 or id-qcs-pkixQCSyntax-v2, then at least one of semanticsIdentifier or nameRegistrationAuthorities fields must be present.

pkix

normative-requirement §3.2.3 SHALL

The certificate policies extension SHALL be present and SHALL contain the identifier of at least one certificate policy reflecting the CA's practices and procedures. The extension MUST include all policy information needed for certification path validation.

pkix

normative-requirement §3.2.2 SHOULD

The dateOfBirth attribute SHOULD specify GMT 12:00:00 (noon) down to the granularity of seconds to prevent accidental change of date due to time zone adjustments. Compliant certificate parsing applications SHOULD ignore any time data and present only the date.

pkix

normative-requirement §2.4 MUST

The distinguished name MUST be unique for each subject entity certified by the one CA as defined by the issuer name field, for the whole life time of the CA.

pkix, security

normative-requirement §3.2.6.1 MUST NOT

The id-qcs-pkixQCSyntax-v1 statement MUST NOT be included in certificates issued in accordance with this profile (RFC 3739); it is provided solely for identification of old certificates issued in conformance with the obsoleted RFC 3039.

pkix

normative-requirement §3.1.1 SHALL

The issuer field SHALL identify the organization responsible for issuing the certificate, using an appropriate subset of domainComponent, countryName, stateOrProvinceName, organizationName, localityName, and serialNumber. Additional attributes MAY be present but SHOULD NOT be necessary to identify the issuing organization.

pkix

normative-requirement §3.2.4 SHALL

The key usage extension SHALL be present with settings in accordance with RFC 3280 definitions. The key usage extension SHOULD be marked critical.

pkix, security

normative-requirement §3.1.2 MUST NOT

The pseudonym attribute type SHALL, if present, contain a pseudonym of the subject. Use of the pseudonym attribute MUST NOT be combined with use of any of the attributes surname and/or givenName.

pkix, privacy

normative-requirement §3.1.2 SHALL

The serialNumber attribute type SHALL, when present, be used to differentiate between names where the subject field would otherwise be identical; it is the CA's responsibility to ensure the serialNumber is sufficient to resolve any subject name collisions.

pkix

normative-requirement §3.1.2 SHALL

The subject field SHALL include at least one of commonName, givenName, or pseudonym. Other attributes listed in the profile are sufficient to ensure unique subject names; use of other attributes MUST NOT be necessary to distinguish subject names.

pkix

normative-requirement §3.2.2 MUST NOT

The subjectDirectoryAttributes extension MUST NOT be marked critical. Compliant implementations SHALL be able to interpret dateOfBirth, placeOfBirth, gender, countryOfCitizenship, and countryOfResidence attributes.

pkix

privacy-consideration §3.2.5

Since the retrieval of biometric data via sourceDataUri may itself reveal sensitive identity information, deployers should consider using URIs that cannot be easily tied by outsiders to the identities of those whose information is being retrieved.

pkix, privacy

protocol-element §3.2.5

The biometricInfo extension (id-pe-biometricInfo, OID 1.3.6.1.5.5.7.1.2) is an optional non-critical extension storing a SEQUENCE OF BiometricData, each containing a type indicator, hash algorithm, hash value, and optional source URI for authenticating biometric templates without storing the raw biometric data.

pkix, security

protocol-element §3.2.6

The qcStatements extension (id-pe-qcStatements, OID 1.3.6.1.5.5.7.1.3) is an optional extension containing a SEQUENCE OF QCStatement, each with a statementId OID and optional statementInfo. It may be critical or non-critical but MUST NOT mix the two — all statements in a single extension share the same criticality.

pkix

protocol-element §3.2.6.1

The SemanticsInformation structure (used in QCStatements) optionally carries a semanticsIdentifier OID defining semantics for certificate attributes, and/or a NameRegistrationAuthorities sequence of GeneralName identifying authorities responsible for name registration.

pkix

protocol-element §3.2.2

The subjectDirectoryAttributes extension is a non-critical optional extension that MAY contain dateOfBirth, placeOfBirth, gender, countryOfCitizenship, and countryOfResidence as attributes supplementing the subject field, useful for authorization purposes.

pkix

registry §A.1

This document defines OID arcs id-pda (1.3.6.1.5.5.7.9) for personal data attributes (dateOfBirth, placeOfBirth, gender, countryOfCitizenship, countryOfResidence) and id-qcs (1.3.6.1.5.5.7.11) for QC statements (pkixQCSyntax-v1, pkixQCSyntax-v2), under the PKIX arc id-pkix.

pkix, registry

security-consideration §4

CAs should not issue CA certificates with policy mapping extensions indicating acceptance of another CA's policy unless the private key uniqueness and sole-control conditions are met.

pkix, security

security-consideration §4

Combining the nonRepudiation bit in the keyUsage extension with other keyUsage bits may have security implications depending on the usage context. Applications validating electronic signatures based on such certificates should determine whether the key usage combination is appropriate.

pkix, security

security-consideration §4

Comparing two qualified certificates to determine if they represent the same physical entity depends on the semantics of subjects' names, which may differ between issuers. Comparing names without knowledge of their semantics in particular certificates may provide misleading results.

pkix, security

security-consideration §4

The associated private key for a Qualified Certificate must be unique for the subject and maintained under the subject's sole control. A CA should not issue a qualified certificate if the means to use the private key is not protected against unintended usage, implying the CA requires knowledge of the subject's cryptographic module.

pkix, security, crypto

wire-format §3.2.5

BiometricData is encoded as a SEQUENCE of typeOfBiometricData (CHOICE of PredefinedBiometricType INTEGER or OID), hashAlgorithm (AlgorithmIdentifier), biometricDataHash (OCTET STRING), and optional sourceDataUri (IA5String). PredefinedBiometricType values are picture(0) and handwritten-signature(1).

pkix

wire-format §A.1

Gender is encoded as PrintableString SIZE(1) constrained to 'M', 'F', 'm', or 'f'. CountryOfCitizenship and CountryOfResidence are encoded as PrintableString SIZE(2) using ISO 3166 country codes. DateOfBirth uses GeneralizedTime.

pkix

wire-format §3.2.6

QCStatement is encoded as a SEQUENCE of statementId (OBJECT IDENTIFIER) and optional statementInfo (ANY DEFINED BY statementId in 1988 ASN.1). QCStatements is a SEQUENCE OF QCStatement.

pkix

wire-format §3.1.2

The subject field allows domainComponent, countryName, commonName, surname, givenName, pseudonym, serialNumber, title, organizationName, organizationalUnitName, stateOrProvinceName, and localityName as distinguished name attributes, all encoded per RFC 3280 and X.520.

pkix