in the DIT.  In cases where the subject name, as specified in the   subject field, specifies a public X.500 directory entry, the   countryName attribute SHOULD always be present.   The commonName attribute value SHALL, when present, contain a name of   the subject.  This MAY be in the subject's preferred presentation   format, or a format preferred by the CA, or some other format.   Pseudonyms, nicknames and names with spelling other than defined by   the registered name MAY be used.  To understand the nature of the   name presented in commonName, complying applications MAY have to   examine present values of the givenName and surname attributes, or   the pseudonym attribute.Santesson, et al.           Standards Track                     [Page 7]RFC 3039             Qualified Certificates Profile         January 2001   Note: Many client implementations presuppose the presence of the   commonName attribute value in the subject field and use this value to   display the subject's name regardless of present givenName, surname   or pseudonym attribute values.   The surname and givenName attribute types SHALL, if present, contain   the registered name of the subject, in accordance with the laws under   which the CA prepares the certificate.  These attributes SHALL be   used in the subject field if the commonName attribute is not present.   In cases where the subject only has a single name registered, the   givenName attribute SHALL be used and the surname attribute SHALL be   omitted.   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.   The serialNumber attribute type SHALL, when present, be used to   differentiate between names where the subject field would otherwise   be identical.  This attribute has no defined semantics beyond   ensuring uniqueness of subject names.  It MAY contain a number or   code assigned by the CA or an identifier assigned by a government or   civil authority.  It is the CA's responsibility to ensure that the   serialNumber is sufficient to resolve any subject name collisions.   The organizationName and the organizationalUnitName attribute types   SHALL, when present, be used to store the name and relevant   information of an organization with which the subject is associated.   The type of association between the organization and the subject is   beyond the scope of this document.   The postalAddress, the stateOrProvinceName and the localityName   attribute types SHALL, when present, be used to store address and   geographical information with which the subject is associated.  If an   organizationName value also is present then the postalAddress,   stateOrProvinceName and localityName attribute values SHALL be   associated with the specified organization.  The type of association   between the postalAddress, stateOrProvinceName and the localityName   and either the subject or the organizationName is beyond the scope of   this document.   Compliant implementations SHALL be able to interpret the attributes   named in this section.Santesson, et al.           Standards Track                     [Page 8]RFC 3039             Qualified Certificates Profile         January 20013.2  Certificate Extensions   This specification provides additional details regarding the contents   of five certificate extensions.  These extensions are the subject   directory attributes, certificate policies, key usage, private   extension for biometric information and private extension for   Qualified Certificate statements.3.2.1  Subject Directory Attributes   The subjectDirectoryAttributes extension MAY contain additional   attributes, associated with the subject, as complement to present   information in the subject field and the subject alternative name   extension.   Attributes suitable for storage in this extension are attributes,   which are not part of the subject's distinguished name, but which MAY   still be useful for other purposes (e.g., authorization).   This extension MUST NOT be marked critical.   Compliant implementations SHALL be able to interpret the following   attributes:      title;      dateOfBirth;      placeOfBirth;      gender;      countryOfCitizenship; and      countryOfResidence.   Other attributes MAY be included according to local definitions.   The title attribute type SHALL, when present, be used to store a   designated position or function of the subject within the   organization specified by present organizational attributes in the   subject field.  The association between the title, the subject and   the organization is beyond the scope of this document.   The dateOfBirth attribute SHALL, when present, contain the value of   the date of birth of the subject.  The manner in which the date of   birth is associated with the subject is outside the scope of this   document.   The placeOfBirth attribute SHALL, when present, contain the value of   the place of birth of the subject.  The manner in which the place of   birth is associated with the subject is outside the scope of this   document.Santesson, et al.           Standards Track                     [Page 9]RFC 3039             Qualified Certificates Profile         January 2001   The gender attribute SHALL, when present, contain the value of the   gender of the subject.  For females the value "F" (or "f") and for   males the value "M" (or "m") have to be used.  The manner in which   the gender is associated with the subject is outside the scope of   this document.   The countryOfCitizenship attribute SHALL, when present, contain the   identifier of at least one of the subject's claimed countries of   citizenship at the time that the certificate was issued.  If the   subject is a citizen of more than one country, more than one country   MAY be present.  Determination of citizenship is a matter of law and   is outside the scope of this document.   The countryOfResidence attribute SHALL, when present, contain the   value of at least one country in which the subject is resident.  If   the subject is a resident of more than one country, more than one   country MAY be present.  Determination of residence is a matter of   law and is outside the scope of this document.3.2.2 Certificate Policies   The certificate policies extension SHALL contain the identifier of at   least one certificate policy which reflects the practices and   procedures undertaken by the CA.  The certificate policy extension   MAY be marked critical.   Information provided by the issuer stating the purpose of the   certificate as discussed in Section 2.2 SHOULD be evident through   indicated policies.   The certificate policies extension SHOULD include all policy   information needed for validation of the certificate.  If policy   information is included in the QCStatements extension (see 3.2.5),   then this information SHOULD also be defined by indicated policies.   Certificate policies MAY be combined with any qualifier defined in   RFC 2459.3.2.3  Key Usage   The key usage extension SHALL be present.  If the key usage   nonRepudiation bit is asserted then it SHOULD NOT be combined with   any other key usage , i.e., if set, the key usage non-repudiation   SHOULD be set exclusively.   The key usage extension MAY be marked critical.Santesson, et al.           Standards Track                    [Page 10]RFC 3039             Qualified Certificates Profile         January 20013.2.4  Biometric Information   This section defines an extension for storage of biometric   information.  Biometric information is stored in the form of a hash   of a biometric template.   The purpose of this extension is to provide means for authentication   of biometric information.  The biometric information that corresponds   to the stored hash is not stored in this extension, but the extension   MAY include an URI pointing to a location where this information can   be obtained.  If included, this URI does not imply that this is the   only way to access this information.   It is RECOMMENDED that biometric information in this extension is   limited to information types suitable for human verification, i.e.,   where the decision of whether the information is an accurate   representation of the subject is naturally performed by a person.   This implies a usage where the biometric information is represented   by, for example, a graphical image displayed to the relying party,   which MAY be used by the relying party to enhance identification of   the subject.   This extension MUST NOT be marked critical.      biometricInfo  EXTENSION ::= {          SYNTAX             BiometricSyntax          IDENTIFIED BY      id-pe-biometricInfo }      id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}      BiometricSyntax ::= SEQUENCE OF BiometricData      BiometricData ::= SEQUENCE {          typeOfBiometricData  TypeOfBiometricData,          hashAlgorithm        AlgorithmIdentifier,          biometricDataHash    OCTET STRING,          sourceDataUri        IA5String OPTIONAL }      TypeOfBiometricData ::= CHOICE {          predefinedBiometricType    PredefinedBiometricType,          biometricDataID            OBJECT IDENTIFIER }      PredefinedBiometricType ::= INTEGER { picture(0),          handwritten-signature(1)} (picture|handwritten-signature,...)Santesson, et al.           Standards Track                    [Page 11]RFC 3039             Qualified Certificates Profile         January 2001   The predefined biometric type picture, when present, SHALL identify   that the source picture is in the form of a displayable graphical   image of the subject.  The hash of the graphical image SHALL only be   calculated over the image data excluding any labels defining the   image type.   The predefined biometric type handwritten-signature, when present,   SHALL identify that the source data is in the form of a displayable   graphical image of the subject's handwritten signature.  The hash of   the graphical image SHALL only be calculated over the image data   excluding any labels defining the image type.3.2.5  Qualified Certificate Statements   This section defines an extension for inclusion of defined statements   related to Qualified Certificates.   A typical statement suitable for inclusion in this extension MAY be a   statement by the issuer that the certificate is issued as a Qualified   Certificate in accordance with a particular legal system (as   discussed in Section 2.2).   Other statements suitable for inclusion in this extension MAY be   statements related to the applicable legal jurisdiction within which   the certificate is issued.  As an example this MAY include a maximum   reliance limit for the certificate indicating restrictions on CA's   liability.   Each statement SHALL include an object identifier for the statement   and MAY also include optional qualifying data contained in the   statementInfo parameter.   If the statementInfo parameter is included then the object identifier   of the statement SHALL define the syntax and SHOULD define the   semantics of this parameter.  If the object identifier does not   define the semantics, a relying party may have to consult a relevant   certificate policy or CPS to determine the exact semantics.   This extension may be critical or non-critical.  If the extension is   critical, this means that all statements included in the extension   are regarded as critical.      qcStatements  EXTENSION ::= {          SYNTAX             QCStatements          IDENTIFIED BY      id-pe-qcStatements }      id-pe-qcStatements     OBJECT IDENTIFIER ::= { id-pe 3 }Santesson, et al.           Standards Track                    [Page 12]RFC 3039             Qualified Certificates Profile         January 2001      QCStatements ::= SEQUENCE OF QCStatement      QCStatement ::= SEQUENCE {          statementId   QC-STATEMENT.&Id({SupportedStatements}),          statementInfo QC-STATEMENT.&Type          ({SupportedStatements}{@statementId}) OPTIONAL }      SupportedStatements QC-STATEMENT ::= { qcStatement-1,...}3.2.5.1 Predefined Statements   This profile includes one predefined object identifier (id-qcs-   pkixQCSyntax-v1), identifying conformance with syntax and semantics   defined in this profile.  This Qualified Certificate profile is   referred to as version 1.      qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation          IDENTIFIED BY id-qcs-pkixQCSyntax-v1 }      --  This statement identifies conformance with syntax and      --  semantics defined in this Qualified Certificate profile      --  (Version 1). The SemanticsInformation may optionally contain      --  additional semantics information as specified.      SemanticsInformation ::= SEQUENCE {          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,          nameRegistrationAuthorities NameRegistrationAuthorities                                                          OPTIONAL }          (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|           WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})      NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF          GeneralName   The SementicsInformation component identified by id-qcs-   pkixQCSyntax-v1 MAY contain a semantics identifier and MAY identify   one or more name registration authorities.   The semanticsIdentifier component, if present, SHALL contain an OID,   defining semantics for attributes and names in basic certificate   fields and certificate extensions.  The OID may define semantics for   all, or for a subgroup of all present attributes and/or names.   The NameRegistrationAuthorities component, if present, SHALL contain   a name of one or more name registration authorities, responsible for   registration of attributes or names associated with the subject.  The   association between an identified name registration authority and   present attributes MAY be defined by a semantics identifier OID, by a   certificate policy (or CPS) or some other implicit factors.Santesson, et al.           Standards Track                    [Page 13]RFC 3039             Qualified Certificates Profile         January 2001   If a value of type SemanticsInformation is present in a QCStatement   then at least one of the fields semanticsIdentifier and   nameRegistrationAuthorities must be present, as indicated.4  Security Considerations   The legal value of a digital signature that is validated with a   Qualified Certificate will be highly dependent upon the policy   governing the use of the associated private key.  Both the private   key holder as well as the relying party should make sure that the   private key is used only with the consent of the legitimate key   holder.   Since the public keys are for public use with legal implications for   involved parties, certain conditions should exist before CAs issue   certificates as Qualified Certificates.  The associated private keys