Summary

  • RFC 3739 let an issuer express that a natural-person certificate served a qualified purpose and bind that statement, identity attributes and policy references into an X.509 profile.
  • It did not define which certificates qualified under law or what legal effect a relying party had to assign them; a valid signature could authenticate the issuer's words without resolving their legal meaning.

The word on the certificate, and the question outside it

Imagine a relying party receives a correctly signed certificate whose issuer describes it as “qualified.” The signature answers a narrow cryptographic question: did the holder of the issuer's signing key sign these certificate bytes, and have those bytes changed? It does not answer who was legally entitled to issue the credential, which statute applies, whether the named person meets that statute's conditions, or what legal effect follows from using the certificate. Those questions sit outside the signature operation.

RFC 3739, published in March 2004, drew that boundary into the design of Internet public-key infrastructure. It updated RFC 3039's Qualified Certificates Profile and built on RFC 3280's X.509 certificate profile. Its scope was identity certificates for natural persons. The standard described conventions for certificates that could be “qualified” within a defined legal framework, but said plainly that it did not define the legal requirements. Its aim was a profile that could support issuance across differing local requirements, not a universal law packaged as ASN.1.

That distinction is the central historical point. A profile can standardize where information goes, how an extension is represented and what an issuer must include. It cannot make a claim true simply by giving it a field, nor can a protocol document settle the legal rules that govern every place a certificate might be presented.

Turning purpose into signed data

The profile gave a certificate authority ways to express its intent. A certificate policy identifier could point to the policy under which the certificate was issued. An optional Qualified Certificate Statements extension could carry statements identified by object identifiers, with optional qualifying data. An issuer could state that a certificate was issued as qualified under a particular legal system, or include jurisdictional information such as a maximum reliance limit tied to its liability.

These mechanisms matter because they make a claim inspectable and bind it into the signed certificate. They do not make an object identifier self-explanatory. The RFC assumed the issuing CA would follow a certificate policy consistent with its liabilities, practices and procedures. It also warned that a relying party might have to consult the certificate policy or the CA's Certification Practice Statement to understand the semantics of issuer-name fields. The policy, issuer and applicable framework supply context that the certificate's structure alone cannot manufacture.

RFC 3739 therefore separated two decisions that can look deceptively similar. The issuer can declare the purpose for which it issued a certificate. A relying party must decide whether that issuer, policy, certificate and purpose are acceptable for the operation at hand. A signature can protect the declaration against undetected alteration; it cannot compel every relying party to accept it or settle the declaration's legal consequence.

Identity fields are not identity conclusions

The profile also specified how natural-person identity could be represented. A subject name could use a real name or a pseudonym. The subject-directory-attributes extension could hold date and place of birth, gender, citizenship or residence. The RFC made an important distinction: countryName in the distinguished name supplies context for interpreting other attributes; it does not necessarily mean citizenship, residence or the country where the certificate was issued.

The document warned that comparing two qualified certificates to determine whether they represent the same person depends on the semantics assigned to their names and attributes by their issuers. Compare fields without that context and a relying party can draw a misleading conclusion. The schema creates a common place to put values; it does not certify that an attribute was correctly observed, that two similar names identify one human, or that the person satisfies a law.

The biometric extension makes the boundary more visible. It can carry a biometric type, hash algorithm, hash and optional URI for source data. The RFC recommended biometric types suitable for human verification and noted the sensitivity of a URI that could reveal whose identifying data was being checked. It required the extension not to be critical. A hash can bind a later comparison to particular data; it cannot establish that the sample was collected lawfully, accurately matched, or interpreted with legal authority. Those remain separate evidentiary and policy questions.

Version continuity without pretending the worlds are the same

RFC 3739 obsoleted RFC 3039, but did not erase its predecessor's vocabulary. The earlier profile's QC-statement identifier remained available to identify older version-1 certificates; a new version-2 statement identified conformance with RFC 3739, and the old identifier was not to appear in certificates issued under the new profile. The revision also aligned the profile with RFC 3280, added subject-name attributes such as domainComponent and title, removed postalAddress, and relaxed some key-usage constraints to make the profile more broadly applicable.

That is an interoperability design, not a record of successful migration. RFC 3739's example certificate is illustrative; the RFC and its predecessor do not establish issuance volume, implementation support or acceptance by any particular relying party. The current RFC Editor record identifies RFC 3739 as a Proposed Standard and RFC 3039 as the document it obsoleted. Those publication facts describe standards status, not field prevalence.

There is even a small reminder that normative syntax is maintained work: Errata 7802, reported in 2024 and held for document update, identifies a misspelling in the normative 1988 ASN.1 module's semanticsIdentifier field name. The erratum is not evidence of a deployed failure. It shows why protocol text, corrected specification and running implementation must be treated as different evidence layers.

RFC 3739's contribution was neither to decide the law nor to make identity self-proving. It standardized a way for issuers to encode purpose, policy references and person-related attributes within a certificate. It left the meaning of “qualified,” the issuer's actual practices, the truth of asserted data and the relying party's legal decision outside that encoding. A signed statement is a verifiable statement. It is not, by itself, the verdict that a legal system or relying party must reach.

Sources