doc/protocol/rfc3039.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                       S. Santesson
   8 Request for Comments: 3039                                      AddTrust
   9 Category: Standards Track                                        W. Polk
  10                                                                     NIST
  11                                                                P. Barzin
  12                                                                   SECUDE
  13                                                               M. Nystrom
  14                                                             RSA Security
  15                                                             January 2001
  16
  17
  18                 Internet X.509 Public Key Infrastructure
  19                      Qualified Certificates Profile
  20
  21 Status of this Memo
  22
  23    This document specifies an Internet standards track protocol for the
  24    Internet community, and requests discussion and suggestions for
  25    improvements.  Please refer to the current edition of the "Internet
  26    Official Protocol Standards" (STD 1) for the standardization state
  27    and status of this protocol.  Distribution of this memo is unlimited.
  28
  29 Copyright Notice
  30
  31    Copyright (C) The Internet Society (2001).  All Rights Reserved.
  32
  33 Abstract
  34
  35    This document forms a certificate profile for Qualified Certificates,
  36    based on RFC 2459, for use in the Internet.  The term Qualified
  37    Certificate is used to describe a certificate with a certain
  38    qualified status within applicable governing law.  Further, Qualified
  39    Certificates are issued exclusively to physical persons.
  40
  41    The goal of this document is to define a general syntax independent
  42    of local legal requirements.  The profile is however designed to
  43    allow further profiling in order to meet specific local needs.
  44
  45    It is important to note that the profile does not define any legal
  46    requirements for Qualified Certificates.
  47
  48    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  49    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  50    document are to be interpreted as described in RFC 2119.
  51
  52
  53
  54
  55
  56
  57
  58 Santesson, et al.           Standards Track                     [Page 1]
  59 \f
  60 RFC 3039             Qualified Certificates Profile         January 2001
  61
  62
  63 Table of Contents
  64
  65    1  Introduction ................................................    2
  66    2  Requirements and Assumptions ................................    3
  67    2.1  Properties ................................................    4
  68    2.2  Statement of Purpose ......................................    5
  69    2.3  Policy Issues .............................................    5
  70    2.4  Uniqueness of names .......................................    5
  71    3  Certificate and Certificate Extensions Profile ..............    6
  72    3.1  Basic Certificate Fields ..................................    6
  73    3.1.1  Issuer ..................................................    6
  74    3.1.2  Subject .................................................    6
  75    3.2  Certificate Extensions ....................................    9
  76    3.2.1  Subject Directory Attributes ............................    9
  77    3.2.2  Certificate Policies ....................................   10
  78    3.2.3  Key Usage ...............................................   10
  79    3.2.4  Biometric Information ...................................   11
  80    3.2.5  Qualified Certificate Statements ........................   12
  81    4  Security Considerations .....................................   14
  82    5  References ..................................................   15
  83    6  Intellectual Property Rights ................................   16
  84    A  ASN.1 definitions ...........................................   17
  85    A.1  1988 ASN.1 Module .........................................   17
  86    A.2  1993 ASN.1 Module .........................................   19
  87    B  A Note on Attributes ........................................   24
  88    C.  Example Certificate ........................................   24
  89    C.1  ASN.1 Structure ...........................................   25
  90    C.1.1 Extensions ...............................................   25
  91    C.1.2 The certificate ..........................................   27
  92    C.2  ASN.1 Dump ................................................   29
  93    C.3  DER-encoding ..............................................   32
  94    C.4  CA's public key ...........................................   33
  95    Authors' Addresses .............................................   34
  96    Full Copyright Statement .......................................   35
  97
  98 1  Introduction
  99
 100    This specification is one part of a family of standards for the X.509
 101    Public Key Infrastructure (PKI) for the Internet.  It is based on RFC
 102    2459, which defines underlying certificate formats and semantics
 103    needed for a full implementation of this standard.
 104
 105    The standard profiles the format for a specific type of certificates
 106    named Qualified Certificates.  The term Qualified Certificates and
 107    the assumptions that affects the scope of this document are discussed
 108    in Section 2.
 109
 110
 111
 112
 113
 114 Santesson, et al.           Standards Track                     [Page 2]
 115 \f
 116 RFC 3039             Qualified Certificates Profile         January 2001
 117
 118
 119    Section 3 defines requirements on information content in Qualified
 120    Certificates.  This profile addresses two fields in the basic
 121    certificate as well as five certificate extensions.  The certificate
 122    fields are the subject and issuer fields.  The certificate extensions
 123    are subject directory attributes, certificate policies, key usage, a
 124    private extension for storage of biometric data and a private
 125    extension for storage of statements related to Qualified
 126    Certificates.  The private extensions are presented in the 1993
 127    Abstract Syntax Notation One (ASN.1), but in conformance with RFC
 128    2459 the 1988 ASN.1 module in Appendix A contains all normative
 129    definitions (the 1993 module in Appendix A is informative).
 130
 131    In Section 4, some security considerations are discussed in order to
 132    clarify the security context in which Qualified Certificates are
 133    assumed to be utilized.  Section 5 contains the references.
 134
 135    Appendix A contains all relevant ASN.1 [X.680] structures that are
 136    not already defined in RFC 2459.  Appendix B contains a note on
 137    attributes.  Appendix C contains an example certificate.  Appendix D
 138    contains authors' addresses and Appendix E contains the IETF
 139    Copyright Statement.
 140
 141    It should be noted that this specification does not define the
 142    specific semantics of Qualified Certificates, and does not define the
 143    policies that should be used with them.  That is, this document
 144    defines what information should go into Qualified Certificates, but
 145    not what that information means.  A system that uses Qualified
 146    Certificates must define its own semantics for the information in
 147    Qualified Certificates.  It is expected that laws and corporate
 148    policies will make these definitions.
 149
 150 2  Requirements and Assumptions
 151
 152    The term "Qualified Certificate" has been used by the European
 153    Commission to describe a certain type of certificates with specific
 154    relevance for European legislation.  This specification is intended
 155    to support this class of certificates, but its scope is not limited
 156    to this application.
 157
 158    Within this standard the term "Qualified Certificate" is used more
 159    generally, describing the format for a certificate whose primary
 160    purpose is identifying a person with high level of assurance in
 161    public non-repudiation services.  The actual mechanisms that will
 162    decide whether a certificate should or should not be considered to be
 163    a "Qualified Certificate" in regard to any legislation are outside
 164    the scope of this standard.
 165
 166
 167
 168
 169
 170 Santesson, et al.           Standards Track                     [Page 3]
 171 \f
 172 RFC 3039             Qualified Certificates Profile         January 2001
 173
 174
 175    Harmonization in the field of Qualified Certificates is essential
 176    within several aspects that fall outside the scope of RFC 2459.  The
 177    most important aspects that affect the scope of this specification
 178    are:
 179
 180    -  Definition of names and identity information in order to identify
 181       the associated subject in a uniform way.
 182
 183    -  Definition of information which identifies the CA and the
 184       jurisdiction under which the CA operates when issuing a particular
 185       certificate.
 186
 187    -  Definition of key usage extension usage for Qualified
 188       Certificates.
 189
 190    -  Definition of information structure for storage of biometric
 191       information.
 192
 193    -  Definition of a standardized way to store predefined statements
 194       with relevance for Qualified Certificates.
 195
 196    -  Requirements for critical extensions.
 197
 198 2.1  Properties
 199
 200    A Qualified Certificate as defined in this standard is assumed to
 201    have the following properties:
 202
 203    -  The certificate is issued by a CA that makes a public statement
 204       that the certificate serves the purpose of a Qualified
 205       Certificate, as discussed in Section 2.2
 206
 207    -  The certificate indicates a certificate policy consistent with
 208       liabilities, practices and procedures undertaken by the CA, as
 209       discussed in 2.3
 210
 211    -  The certificate is issued to a natural person (living human
 212       being).
 213
 214    -  The certificate contains an identity based on a pseudonym or a
 215       real name of the subject.
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Santesson, et al.           Standards Track                     [Page 4]
 227 \f
 228 RFC 3039             Qualified Certificates Profile         January 2001
 229
 230
 231 2.2  Statement of Purpose
 232
 233    For a certificate to serve the purpose of being a Qualified
 234    Certificate, this profile assumes that the CA will have to include in
 235    the certificate information that explicitly defines this intent.
 236
 237    The function of this information is thus to assist any concerned
 238    entity in evaluating the risk associated with creating or accepting
 239    signatures that are based on a Qualified Certificate.
 240
 241    This profile defines two complementary ways to include this
 242    information:
 243
 244    -  As information defined by a certificate policy included in the
 245       certificate policies extension, and
 246
 247    -  As a statement included in the Qualified Certificates Statements
 248       extension.
 249
 250 2.3  Policy Issues
 251
 252    Certain policy aspects define the context in which this profile is to
 253    be understood and used.  It is however outside the scope of this
 254    profile to specify any policies or legal aspects that will govern
 255    services that issue or utilize certificates according to this
 256    profile.
 257
 258    It is however assumed that the issuing CA will undertake to follow a
 259    publicly available certificate policy that is consistent with its
 260    liabilities, practices and procedures.
 261
 262 2.4  Uniqueness of names
 263
 264    Distinguished name is originally defined in X.501 [X.501] as a
 265    representation of a directory name, defined as a construct that
 266    identifies a particular object from among the set of all objects.  An
 267    object can be assigned a distinguished name without being represented
 268    by an entry in the Directory, but this name is then the name its
 269    object entry could have had if it were represented in the Directory.
 270    In the context of qualified certificates, a distinguished name
 271    denotes a set of attribute values [X.501] which forms a name that is
 272    unambiguous within a certain domain that forms either a real or a
 273    virtual DIT (Directory Information Tree)[X.501].  In the case of
 274    subject names the domain is assumed to be at least the issuing domain
 275    of the CA.  The distinguished name MUST be unique for each subject
 276    entity certified by the one CA as defined by the issuer name field,
 277    during the whole life time of the CA.
 278
 279
 280
 281
 282 Santesson, et al.           Standards Track                     [Page 5]
 283 \f
 284 RFC 3039             Qualified Certificates Profile         January 2001
 285
 286
 287 3  Certificate and Certificate Extensions Profile
 288
 289    This section defines a profile for Qualified Certificates.  The
 290    profile is based on the Internet certificate profile RFC 2459 which
 291    in turn is based on the X.509 version 3 format.  For full
 292    implementation of this section implementers are REQUIRED to consult
 293    the underlying formats and semantics defined in RFC 2459.
 294
 295    ASN.1 definitions relevant for this section that are not supplied by
 296    RFC 2459 are supplied in Appendix A.
 297
 298 3.1  Basic Certificate Fields
 299
 300    This specification provides additional details regarding the contents
 301    of two fields in the basic certificate.  These fields are the issuer
 302    and subject fields.
 303
 304 3.1.1  Issuer
 305
 306    The issuer field SHALL identify the organization responsible for
 307    issuing the certificate.  The name SHOULD be an officially registered
 308    name of the organization.
 309
 310    The identity of the issuer SHALL be specified using an appropriate
 311    subset of the following attributes:
 312
 313          domainComponent;
 314          countryName;
 315          stateOrProvinceName;
 316          organizationName;
 317          localityName; and
 318          serialNumber.
 319
 320    Additional attributes MAY be present but they SHOULD NOT be necessary
 321    to identify the issuing organization.
 322
 323    Attributes present in the issuer field SHOULD be consistent with the
 324    laws under which the issuer operates.
 325
 326    A relying party MAY have to consult associated certificate policies
 327    and/or the issuer's CPS, in order to determine the semantics of name
 328    fields and the laws under which the issuer operates.
 329
 330 3.1.2  Subject
 331
 332    The subject field of a certificate compliant with this profile SHALL
 333    contain a distinguished name of the subject (see 2.4 for definition
 334    of distinguished name).
 335
 336
 337
 338 Santesson, et al.           Standards Track                     [Page 6]
 339 \f
 340 RFC 3039             Qualified Certificates Profile         January 2001
 341
 342
 343    The subject field SHALL contain an appropriate subset of the
 344    following attributes:
 345
 346       countryName;
 347       commonName;
 348       surname;
 349       givenName;
 350       pseudonym;
 351       serialNumber;
 352       organizationName;
 353       organizationalUnitName;
 354       stateOrProvinceName
 355       localityName and
 356       postalAddress.
 357
 358    Other attributes may be present but MUST NOT be necessary to
 359    distinguish the subject name from other subject names within the
 360    issuer domain.
 361
 362    Of these attributes, the subject field SHALL include at least one of
 363    the following:
 364
 365       Choice   I:  commonName
 366       Choice  II:  givenName
 367       Choice III:  pseudonym
 368
 369    The countryName attribute value specifies a general context in which
 370    other attributes are to be understood.  The country attribute does
 371    not necessarily indicate the subject's country of citizenship or
 372    country of residence, nor does it have to indicate the country of
 373    issuance.
 374
 375    Note: Many X.500 implementations require the presence of countryName
 376    in the DIT.  In cases where the subject name, as specified in the
 377    subject field, specifies a public X.500 directory entry, the
 378    countryName attribute SHOULD always be present.
 379
 380    The commonName attribute value SHALL, when present, contain a name of
 381    the subject.  This MAY be in the subject's preferred presentation
 382    format, or a format preferred by the CA, or some other format.
 383    Pseudonyms, nicknames and names with spelling other than defined by
 384    the registered name MAY be used.  To understand the nature of the
 385    name presented in commonName, complying applications MAY have to
 386    examine present values of the givenName and surname attributes, or
 387    the pseudonym attribute.
 388
 389
 390
 391
 392
 393
 394 Santesson, et al.           Standards Track                     [Page 7]
 395 \f
 396 RFC 3039             Qualified Certificates Profile         January 2001
 397
 398
 399    Note: Many client implementations presuppose the presence of the
 400    commonName attribute value in the subject field and use this value to
 401    display the subject's name regardless of present givenName, surname
 402    or pseudonym attribute values.
 403
 404    The surname and givenName attribute types SHALL, if present, contain
 405    the registered name of the subject, in accordance with the laws under
 406    which the CA prepares the certificate.  These attributes SHALL be
 407    used in the subject field if the commonName attribute is not present.
 408    In cases where the subject only has a single name registered, the
 409    givenName attribute SHALL be used and the surname attribute SHALL be
 410    omitted.
 411
 412    The pseudonym attribute type SHALL, if present, contain a pseudonym
 413    of the subject.  Use of the pseudonym attribute MUST NOT be combined
 414    with use of any of the attributes surname and/or givenName.
 415
 416    The serialNumber attribute type SHALL, when present, be used to
 417    differentiate between names where the subject field would otherwise
 418    be identical.  This attribute has no defined semantics beyond
 419    ensuring uniqueness of subject names.  It MAY contain a number or
 420    code assigned by the CA or an identifier assigned by a government or
 421    civil authority.  It is the CA's responsibility to ensure that the
 422    serialNumber is sufficient to resolve any subject name collisions.
 423
 424    The organizationName and the organizationalUnitName attribute types
 425    SHALL, when present, be used to store the name and relevant
 426    information of an organization with which the subject is associated.
 427    The type of association between the organization and the subject is
 428    beyond the scope of this document.
 429
 430    The postalAddress, the stateOrProvinceName and the localityName
 431    attribute types SHALL, when present, be used to store address and
 432    geographical information with which the subject is associated.  If an
 433    organizationName value also is present then the postalAddress,
 434    stateOrProvinceName and localityName attribute values SHALL be
 435    associated with the specified organization.  The type of association
 436    between the postalAddress, stateOrProvinceName and the localityName
 437    and either the subject or the organizationName is beyond the scope of
 438    this document.
 439
 440    Compliant implementations SHALL be able to interpret the attributes
 441    named in this section.
 442
 443
 444
 445
 446
 447
 448
 449
 450 Santesson, et al.           Standards Track                     [Page 8]
 451 \f
 452 RFC 3039             Qualified Certificates Profile         January 2001
 453
 454
 455 3.2  Certificate Extensions
 456
 457    This specification provides additional details regarding the contents
 458    of five certificate extensions.  These extensions are the subject
 459    directory attributes, certificate policies, key usage, private
 460    extension for biometric information and private extension for
 461    Qualified Certificate statements.
 462
 463 3.2.1  Subject Directory Attributes
 464
 465    The subjectDirectoryAttributes extension MAY contain additional
 466    attributes, associated with the subject, as complement to present
 467    information in the subject field and the subject alternative name
 468    extension.
 469
 470    Attributes suitable for storage in this extension are attributes,
 471    which are not part of the subject's distinguished name, but which MAY
 472    still be useful for other purposes (e.g., authorization).
 473
 474    This extension MUST NOT be marked critical.
 475
 476    Compliant implementations SHALL be able to interpret the following
 477    attributes:
 478
 479       title;
 480       dateOfBirth;
 481       placeOfBirth;
 482       gender;
 483       countryOfCitizenship; and
 484       countryOfResidence.
 485
 486    Other attributes MAY be included according to local definitions.
 487
 488    The title attribute type SHALL, when present, be used to store a
 489    designated position or function of the subject within the
 490    organization specified by present organizational attributes in the
 491    subject field.  The association between the title, the subject and
 492    the organization is beyond the scope of this document.
 493
 494    The dateOfBirth attribute SHALL, when present, contain the value of
 495    the date of birth of the subject.  The manner in which the date of
 496    birth is associated with the subject is outside the scope of this
 497    document.
 498
 499    The placeOfBirth attribute SHALL, when present, contain the value of
 500    the place of birth of the subject.  The manner in which the place of
 501    birth is associated with the subject is outside the scope of this
 502    document.
 503
 504
 505
 506 Santesson, et al.           Standards Track                     [Page 9]
 507 \f
 508 RFC 3039             Qualified Certificates Profile         January 2001
 509
 510
 511    The gender attribute SHALL, when present, contain the value of the
 512    gender of the subject.  For females the value "F" (or "f") and for
 513    males the value "M" (or "m") have to be used.  The manner in which
 514    the gender is associated with the subject is outside the scope of
 515    this document.
 516
 517    The countryOfCitizenship attribute SHALL, when present, contain the
 518    identifier of at least one of the subject's claimed countries of
 519    citizenship at the time that the certificate was issued.  If the
 520    subject is a citizen of more than one country, more than one country
 521    MAY be present.  Determination of citizenship is a matter of law and
 522    is outside the scope of this document.
 523
 524    The countryOfResidence attribute SHALL, when present, contain the
 525    value of at least one country in which the subject is resident.  If
 526    the subject is a resident of more than one country, more than one
 527    country MAY be present.  Determination of residence is a matter of
 528    law and is outside the scope of this document.
 529
 530 3.2.2 Certificate Policies
 531
 532    The certificate policies extension SHALL contain the identifier of at
 533    least one certificate policy which reflects the practices and
 534    procedures undertaken by the CA.  The certificate policy extension
 535    MAY be marked critical.
 536
 537    Information provided by the issuer stating the purpose of the
 538    certificate as discussed in Section 2.2 SHOULD be evident through
 539    indicated policies.
 540
 541    The certificate policies extension SHOULD include all policy
 542    information needed for validation of the certificate.  If policy
 543    information is included in the QCStatements extension (see 3.2.5),
 544    then this information SHOULD also be defined by indicated policies.
 545
 546    Certificate policies MAY be combined with any qualifier defined in
 547    RFC 2459.
 548
 549 3.2.3  Key Usage
 550
 551    The key usage extension SHALL be present.  If the key usage
 552    nonRepudiation bit is asserted then it SHOULD NOT be combined with
 553    any other key usage , i.e., if set, the key usage non-repudiation
 554    SHOULD be set exclusively.
 555
 556    The key usage extension MAY be marked critical.
 557
 558
 559
 560
 561
 562 Santesson, et al.           Standards Track                    [Page 10]
 563 \f
 564 RFC 3039             Qualified Certificates Profile         January 2001
 565
 566
 567 3.2.4  Biometric Information
 568
 569    This section defines an extension for storage of biometric
 570    information.  Biometric information is stored in the form of a hash
 571    of a biometric template.
 572
 573    The purpose of this extension is to provide means for authentication
 574    of biometric information.  The biometric information that corresponds
 575    to the stored hash is not stored in this extension, but the extension
 576    MAY include an URI pointing to a location where this information can
 577    be obtained.  If included, this URI does not imply that this is the
 578    only way to access this information.
 579
 580    It is RECOMMENDED that biometric information in this extension is
 581    limited to information types suitable for human verification, i.e.,
 582    where the decision of whether the information is an accurate
 583    representation of the subject is naturally performed by a person.
 584    This implies a usage where the biometric information is represented
 585    by, for example, a graphical image displayed to the relying party,
 586    which MAY be used by the relying party to enhance identification of
 587    the subject.
 588
 589    This extension MUST NOT be marked critical.
 590
 591       biometricInfo  EXTENSION ::= {
 592           SYNTAX             BiometricSyntax
 593           IDENTIFIED BY      id-pe-biometricInfo }
 594
 595       id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}
 596
 597       BiometricSyntax ::= SEQUENCE OF BiometricData
 598
 599       BiometricData ::= SEQUENCE {
 600           typeOfBiometricData  TypeOfBiometricData,
 601           hashAlgorithm        AlgorithmIdentifier,
 602           biometricDataHash    OCTET STRING,
 603           sourceDataUri        IA5String OPTIONAL }
 604
 605       TypeOfBiometricData ::= CHOICE {
 606           predefinedBiometricType    PredefinedBiometricType,
 607           biometricDataID            OBJECT IDENTIFIER }
 608
 609       PredefinedBiometricType ::= INTEGER { picture(0),
 610           handwritten-signature(1)} (picture|handwritten-signature,...)
 611
 612
 613
 614
 615
 616
 617
 618 Santesson, et al.           Standards Track                    [Page 11]
 619 \f
 620 RFC 3039             Qualified Certificates Profile         January 2001
 621
 622
 623    The predefined biometric type picture, when present, SHALL identify
 624    that the source picture is in the form of a displayable graphical
 625    image of the subject.  The hash of the graphical image SHALL only be
 626    calculated over the image data excluding any labels defining the
 627    image type.
 628
 629    The predefined biometric type handwritten-signature, when present,
 630    SHALL identify that the source data is in the form of a displayable
 631    graphical image of the subject's handwritten signature.  The hash of
 632    the graphical image SHALL only be calculated over the image data
 633    excluding any labels defining the image type.
 634
 635 3.2.5  Qualified Certificate Statements
 636
 637    This section defines an extension for inclusion of defined statements
 638    related to Qualified Certificates.
 639
 640    A typical statement suitable for inclusion in this extension MAY be a
 641    statement by the issuer that the certificate is issued as a Qualified
 642    Certificate in accordance with a particular legal system (as
 643    discussed in Section 2.2).
 644
 645    Other statements suitable for inclusion in this extension MAY be
 646    statements related to the applicable legal jurisdiction within which
 647    the certificate is issued.  As an example this MAY include a maximum
 648    reliance limit for the certificate indicating restrictions on CA's
 649    liability.
 650
 651    Each statement SHALL include an object identifier for the statement
 652    and MAY also include optional qualifying data contained in the
 653    statementInfo parameter.
 654
 655    If the statementInfo parameter is included then the object identifier
 656    of the statement SHALL define the syntax and SHOULD define the
 657    semantics of this parameter.  If the object identifier does not
 658    define the semantics, a relying party may have to consult a relevant
 659    certificate policy or CPS to determine the exact semantics.
 660
 661    This extension may be critical or non-critical.  If the extension is
 662    critical, this means that all statements included in the extension
 663    are regarded as critical.
 664
 665       qcStatements  EXTENSION ::= {
 666           SYNTAX             QCStatements
 667           IDENTIFIED BY      id-pe-qcStatements }
 668
 669       id-pe-qcStatements     OBJECT IDENTIFIER ::= { id-pe 3 }
 670
 671
 672
 673
 674 Santesson, et al.           Standards Track                    [Page 12]
 675 \f
 676 RFC 3039             Qualified Certificates Profile         January 2001
 677
 678
 679       QCStatements ::= SEQUENCE OF QCStatement
 680
 681       QCStatement ::= SEQUENCE {
 682           statementId   QC-STATEMENT.&Id({SupportedStatements}),
 683           statementInfo QC-STATEMENT.&Type
 684           ({SupportedStatements}{@statementId}) OPTIONAL }
 685
 686       SupportedStatements QC-STATEMENT ::= { qcStatement-1,...}
 687
 688 3.2.5.1 Predefined Statements
 689
 690    This profile includes one predefined object identifier (id-qcs-
 691    pkixQCSyntax-v1), identifying conformance with syntax and semantics
 692    defined in this profile.  This Qualified Certificate profile is
 693    referred to as version 1.
 694
 695       qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation
 696           IDENTIFIED BY id-qcs-pkixQCSyntax-v1 }
 697       --  This statement identifies conformance with syntax and
 698       --  semantics defined in this Qualified Certificate profile
 699       --  (Version 1). The SemanticsInformation may optionally contain
 700       --  additional semantics information as specified.
 701
 702       SemanticsInformation ::= SEQUENCE {
 703           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
 704           nameRegistrationAuthorities NameRegistrationAuthorities
 705                                                           OPTIONAL }
 706           (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
 707            WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
 708
 709       NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
 710           GeneralName
 711
 712    The SementicsInformation component identified by id-qcs-
 713    pkixQCSyntax-v1 MAY contain a semantics identifier and MAY identify
 714    one or more name registration authorities.
 715
 716    The semanticsIdentifier component, if present, SHALL contain an OID,
 717    defining semantics for attributes and names in basic certificate
 718    fields and certificate extensions.  The OID may define semantics for
 719    all, or for a subgroup of all present attributes and/or names.
 720
 721    The NameRegistrationAuthorities component, if present, SHALL contain
 722    a name of one or more name registration authorities, responsible for
 723    registration of attributes or names associated with the subject.  The
 724    association between an identified name registration authority and
 725    present attributes MAY be defined by a semantics identifier OID, by a
 726    certificate policy (or CPS) or some other implicit factors.
 727
 728
 729
 730 Santesson, et al.           Standards Track                    [Page 13]
 731 \f
 732 RFC 3039             Qualified Certificates Profile         January 2001
 733
 734
 735    If a value of type SemanticsInformation is present in a QCStatement
 736    then at least one of the fields semanticsIdentifier and
 737    nameRegistrationAuthorities must be present, as indicated.
 738
 739 4  Security Considerations
 740
 741    The legal value of a digital signature that is validated with a
 742    Qualified Certificate will be highly dependent upon the policy
 743    governing the use of the associated private key.  Both the private
 744    key holder as well as the relying party should make sure that the
 745    private key is used only with the consent of the legitimate key
 746    holder.
 747
 748    Since the public keys are for public use with legal implications for
 749    involved parties, certain conditions should exist before CAs issue
 750    certificates as Qualified Certificates.  The associated private keys
 751    must be unique for the subject, and must be maintained under the
 752    subject's sole control.  That is, a CA should not issue a qualified
 753    certificate if the means to use the private key is not protected
 754    against unintended usage.  This implies that the CA have some
 755    knowledge about the subject's cryptographic module.
 756
 757    The CA must further verify that the public key contained in the
 758    certificate is legitimately representing the subject.
 759
 760    CAs should not issue CA certificates with policy mapping extensions
 761    indicating acceptance of another CA's policy unless these conditions
 762    are met.
 763
 764    Combining the nonRepudiation bit in the keyUsage certificate
 765    extension with other keyUsage bits may have security implications and
 766    this specification therefore recommends against such practices.
 767
 768    The ability to compare two qualified certificates to determine if
 769    they represent the same physical entity is dependent on the semantics
 770    of the subjects' names.  The semantics of a particular attribute may
 771    be different for different issuers.  Comparing names without
 772    knowledge of the semantics of names in these particular certificates
 773    may provide misleading results.
 774
 775    This specification is a profile of RFC 2459.  The security
 776    considerations section of that document applies to this specification
 777    as well.
 778
 779
 780
 781
 782
 783
 784
 785
 786 Santesson, et al.           Standards Track                    [Page 14]
 787 \f
 788 RFC 3039             Qualified Certificates Profile         January 2001
 789
 790
 791 5 References
 792
 793    [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
 794               Requirement Levels", BCP 14, RFC 2119, March 1997.
 795
 796    [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
 797               Sataluri, "Using Domains in LDAP/X.500 Distinguished
 798               Names", RFC 2247, January 1998.
 799
 800    [RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
 801               X.509 Public Key Infrastructure: Certificate and CRL
 802               Profile", RFC 2459, January 1999.
 803
 804    [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
 805               Classes and Attribute Types Version 2.0", RFC 2985,
 806               November 2000.
 807
 808    [X.501]    ITU-T Recommendation X.501: Information Technology - Open
 809               Systems Interconnection - The Directory: Models, June
 810               1993.
 811
 812    [X.509]    ITU-T Recommendation X.509: Information Technology - Open
 813               Systems Interconnection - The Directory: Authentication
 814               Framework, June 1997.
 815
 816    [X.520]    ITU-T Recommendation X.520: Information Technology - Open
 817               Systems Interconnection - The Directory: Selected
 818               Attribute Types, June 1993.
 819
 820    [X.680]    ITU-T Recommendation X.680: Information Technology -
 821               Abstract Syntax Notation One, 1997.
 822
 823    [ISO 3166] ISO Standard 3166: Codes for the representation of names
 824               of countries, 1993.
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Santesson, et al.           Standards Track                    [Page 15]
 843 \f
 844 RFC 3039             Qualified Certificates Profile         January 2001
 845
 846
 847 6 Intellectual Property Rights
 848
 849    The IETF takes no position regarding the validity or scope of any
 850    intellectual property or other rights that might be claimed to
 851    pertain to the implementation or use of the technology described in
 852    this document or the extent to which any license under such rights
 853    might or might not be available; neither does it represent that it
 854    has made any effort to identify any such rights.  Information on the
 855    IETF's procedures with respect to rights in standards-track and
 856    standards related documentation can be found in BCP-11.  Copies of
 857    claims of rights made available for publication and any assurances of
 858    licenses to be made available, or the result of an attempt made to
 859    obtain a general license or permission for the use of such
 860    proprietary rights by implementors or users of this specification can
 861    be obtained from the IETF Secretariat.
 862
 863    The IETF invites any interested party to bring to its attention any
 864    copyrights, patents or patent applications, or other proprietary
 865    rights which may cover technology that may be required to practice
 866    this standard.  Please address the information to the IETF Executive
 867    Director.
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898 Santesson, et al.           Standards Track                    [Page 16]
 899 \f
 900 RFC 3039             Qualified Certificates Profile         January 2001
 901
 902
 903 A. ASN.1 definitions
 904
 905    As in RFC 2459, ASN.1 modules are supplied in two different variants
 906    of the ASN.1 syntax.
 907
 908    Appendix A.1 is in the 1988 syntax, and does not use macros.
 909    However, since the module imports type definitions from modules in
 910    RFC 2459 which are not completely in the 1988 syntax, the same
 911    comments as in RFC 2459 regarding its use applies here as well; i.e.,
 912    Appendix A.1 may be parsed by an 1988 ASN.1-parser by removing the
 913    definitions for the UNIVERSAL types and all references to them in RFC
 914    2459's 1988 modules.
 915
 916    Appendix A.2 is in the 1993 syntax.  However, since the module
 917    imports type definitions from modules in RFC 2459 which are not
 918    completely in the 1993 syntax, the same comments as in RFC 2459
 919    regarding its use applies here as well; i.e., Appendix A.2 may be
 920    parsed by an 1993 ASN.1-parser by removing the UTF8String choice from
 921    the definition of DirectoryString in the module PKIX1Explicit93 in
 922    RFC 2459.  Appendix A.2 may be parsed "as is" by an 1997 ASN.1
 923    parser, however.
 924
 925    In case of discrepancies between these modules, the 1988 module is
 926    the normative one.
 927
 928 A.1 1988 ASN.1 Module
 929
 930 PKIXqualified88 {iso(1) identified-organization(3) dod(6)
 931     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
 932     id-mod-qualified-cert-88(10) }
 933
 934 DEFINITIONS EXPLICIT TAGS ::=
 935
 936 BEGIN
 937
 938 -- EXPORTS ALL --
 939
 940 IMPORTS
 941
 942 GeneralName
 943     FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
 944     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
 945     id-pkix1-implicit-88(2)}
 946
 947 AlgorithmIdentifier, DirectoryString, Attribute, AttributeType,
 948     id-pkix, id-pe, id-at
 949     FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
 950     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
 951
 952
 953
 954 Santesson, et al.           Standards Track                    [Page 17]
 955 \f
 956 RFC 3039             Qualified Certificates Profile         January 2001
 957
 958
 959     id-pkix1-explicit-88(1)};
 960
 961 -- Locally defined OIDs
 962
 963 -- Arc for QC personal data attributes
 964 id-pda  OBJECT IDENTIFIER ::= { id-pkix 9 }
 965 -- Arc for QC statements
 966 id-qcs  OBJECT IDENTIFIER ::= { id-pkix 11 }
 967
 968 -- Attributes
 969
 970 id-at-serialNumber          AttributeType ::= { id-at 5 }
 971 SerialNumber ::=            PrintableString (SIZE(1..64))
 972
 973 id-at-postalAddress         AttributeType ::= { id-at 16 }
 974 PostalAddress ::=           SEQUENCE SIZE (1..6) OF DirectoryString
 975
 976 id-at-pseudonym             AttributeType ::= { id-at 65 }
 977 Pseudonym ::=               DirectoryString
 978
 979 domainComponent             AttributeType ::=
 980                             { 0 9 2342 19200300 100 1 25 }
 981 DomainComponent ::=         IA5String
 982
 983 id-pda-dateOfBirth          AttributeType ::= { id-pda 1 }
 984 DateOfBirth ::=             GeneralizedTime
 985
 986 id-pda-placeOfBirth         AttributeType ::= { id-pda 2 }
 987 PlaceOfBirth ::=            DirectoryString
 988
 989 id-pda-gender               AttributeType ::= { id-pda 3 }
 990 Gender ::=                  PrintableString (SIZE(1))
 991                             -- "M", "F", "m" or "f"
 992
 993 id-pda-countryOfCitizenship AttributeType ::= { id-pda 4 }
 994 CountryOfCitizenship ::=    PrintableString (SIZE (2))
 995                             -- ISO 3166 Country Code
 996
 997 id-pda-countryOfResidence   AttributeType ::= { id-pda 5 }
 998 CountryOfResidence ::=      PrintableString (SIZE (2))
 999                             -- ISO 3166 Country Code
1000
1001 -- Private extensions
1002
1003 -- Biometric info extension
1004
1005 id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}
1006
1007
1008
1009
1010 Santesson, et al.           Standards Track                    [Page 18]
1011 \f
1012 RFC 3039             Qualified Certificates Profile         January 2001
1013
1014
1015 BiometricSyntax ::= SEQUENCE OF BiometricData
1016
1017 BiometricData ::= SEQUENCE {
1018     typeOfBiometricData  TypeOfBiometricData,
1019     hashAlgorithm        AlgorithmIdentifier,
1020     biometricDataHash    OCTET STRING,
1021     sourceDataUri        IA5String OPTIONAL }
1022
1023 TypeOfBiometricData ::= CHOICE {
1024     predefinedBiometricType   PredefinedBiometricType,
1025     biometricDataOid          OBJECT IDENTIFIER }
1026
1027 PredefinedBiometricType ::= INTEGER {
1028     picture(0),handwritten-signature(1)}
1029     (picture|handwritten-signature)
1030
1031 -- QC Statements Extension
1032
1033 id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3}
1034
1035 QCStatements ::= SEQUENCE OF QCStatement
1036
1037 QCStatement ::= SEQUENCE {
1038     statementId        OBJECT IDENTIFIER,
1039     statementInfo      ANY DEFINED BY statementId OPTIONAL}
1040
1041 -- QC statements
1042 id-qcs-pkixQCSyntax-v1   OBJECT IDENTIFIER ::= { id-qcs 1 }
1043
1044 --  This statement identifies conformance with syntax and
1045 --  semantics defined in this Qualified Certificate profile
1046 --  (Version 1). This statement may optionally contain
1047 --  additional semantics information as specified below.
1048
1049 SemanticsInformation  ::= SEQUENCE {
1050     semanticsIndentifier        OBJECT IDENTIFIER OPTIONAL,
1051     nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
1052     } -- At least one field shall be present
1053
1054 NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName
1055
1056 END
1057
1058 A.2 1993 ASN.1  Module
1059
1060 PKIXqualified93 {iso(1) identified-organization(3) dod(6)
1061     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1062     id-mod-qualified-cert-93(11) }
1063
1064
1065
1066 Santesson, et al.           Standards Track                    [Page 19]
1067 \f
1068 RFC 3039             Qualified Certificates Profile         January 2001
1069
1070
1071 DEFINITIONS EXPLICIT TAGS ::=
1072
1073 BEGIN
1074
1075 -- EXPORTS ALL --
1076
1077 IMPORTS
1078
1079 authorityKeyIdentifier, subjectKeyIdentifier, keyUsage,
1080     extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies,
1081     policyMappings, subjectAltName, issuerAltName, basicConstraints,
1082     nameConstraints, policyConstraints, cRLDistributionPoints,
1083     subjectDirectoryAttributes, authorityInfoAccess, GeneralName,
1084     OTHER-NAME
1085     FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
1086     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1087     id-pkix1-implicit-93(4)}
1088
1089 id-pkix, AlgorithmIdentifier, ATTRIBUTE, Extension, EXTENSION,
1090     DirectoryString{}, ub-name, id-pe, id-at, id-at-commonName,
1091     id-at-surname, id-at-countryName, id-at-localityName,
1092     id-at-stateOrProvinceName, id-at-organizationName,
1093     id-at-organizationalUnitName, id-at-givenName, id-at-dnQualifier,
1094     pkcs9email, title, organizationName, organizationalUnitName,
1095     stateOrProvinceName, localityName, countryName,
1096     generationQualifier, dnQualifier, initials, givenName, surname,
1097     commonName, name
1098     FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
1099     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1100     id-pkix1-explicit-93(3)};
1101
1102 -- Object Identifiers
1103
1104 -- Externally defined OIDs
1105 id-at-serialNumber  OBJECT IDENTIFIER ::= { id-at 5}
1106 id-at-postalAddress OBJECT IDENTIFIER ::= { id-at 16 }
1107 id-at-pseudonym     OBJECT IDENTIFIER ::= { id-at 65 }
1108 id-domainComponent  OBJECT IDENTIFIER ::= { 0 9 2342 19200300 100 1 25 }
1109
1110 -- Locally defined OIDs
1111
1112 -- Arc for QC personal data attributes
1113
1114 id-pda  OBJECT IDENTIFIER ::= { id-pkix 9 }
1115 -- Arc for QC statements
1116 id-qcs  OBJECT IDENTIFIER ::= { id-pkix 11 }
1117
1118 -- Private extensions
1119
1120
1121
1122 Santesson, et al.           Standards Track                    [Page 20]
1123 \f
1124 RFC 3039             Qualified Certificates Profile         January 2001
1125
1126
1127 id-pe-biometricInfo         OBJECT IDENTIFIER ::= { id-pe 2 }
1128 id-pe-qcStatements          OBJECT IDENTIFIER ::= { id-pe 3 }
1129
1130 -- Personal data attributes
1131 id-pda-dateOfBirth          OBJECT IDENTIFIER ::= { id-pda 1 }
1132 id-pda-placeOfBirth         OBJECT IDENTIFIER ::= { id-pda 2 }
1133 id-pda-gender               OBJECT IDENTIFIER ::= { id-pda 3 }
1134 id-pda-countryOfCitizenship OBJECT IDENTIFIER ::= { id-pda 4 }
1135 id-pda-countryOfResidence   OBJECT IDENTIFIER ::= { id-pda 5 }
1136
1137 -- QC statements
1138 id-qcs-pkixQCSyntax-v1      OBJECT IDENTIFIER ::= { id-qcs 1 }
1139
1140 -- Object Sets
1141
1142 -- The following information object set is defined to constrain the
1143 -- set of legal certificate extensions. Note that this set is an
1144 -- extension of the ExtensionSet defined in RFC 2459.
1145 ExtensionSet EXTENSION ::= {
1146     authorityKeyIdentifier |
1147     subjectKeyIdentifier |
1148     keyUsage |
1149     extendedKeyUsage |
1150     privateKeyUsagePeriod |
1151     certificatePolicies |
1152     policyMappings |
1153     subjectAltName |
1154     issuerAltName |
1155     basicConstraints |
1156     nameConstraints |
1157     policyConstraints |
1158     cRLDistributionPoints |
1159     subjectDirectoryAttributes |
1160     authorityInfoAccess |
1161     biometricInfo |
1162     qcStatements, ... }
1163
1164 -- The following information object set is defined to constrain the
1165 -- set of attributes applications are required to recognize in
1166 -- distinguished names. The set may of course be augmented to meet
1167 -- local requirements.  Note that deleting members of the set may
1168 -- prevent interoperability with conforming implementations, and that
1169 -- this set is an extension of the SupportedAttributes set in RFC 2459.
1170
1171 SupportedAttributes ATTRIBUTE ::= {
1172     countryName | commonName | surname | givenName | pseudonym |
1173     serialNumber | organizationName | organizationalUnitName |
1174     stateOrProvinceName | localityName | postalAddress |
1175
1176
1177
1178 Santesson, et al.           Standards Track                    [Page 21]
1179 \f
1180 RFC 3039             Qualified Certificates Profile         January 2001
1181
1182
1183     pkcs9email | domainComponent | dnQualifier,
1184     ... -- For future extensions -- }
1185
1186 -- The following information object set is defined to constrain the
1187 -- set of attributes applications are required to recognize in
1188 -- subjectDirectoryAttribute extensions. The set may be augmented to
1189 -- meet local requirements.  Note that deleting members of the set
1190 -- may prevent interoperability with conforming implementations.
1191 PersonalDataAttributeSet ATTRIBUTE ::= {
1192     title | dateOfBirth | placeOfBirth | gender | countryOfCitizenship |
1193     countryOfResidence, ... }
1194
1195 -- Attributes
1196
1197 -- serialNumber from X.520
1198 serialNumber ATTRIBUTE ::= {
1199     WITH SYNTAX PrintableString (SIZE(1..64))
1200     ID          id-at-serialNumber }
1201
1202 -- postalAddress from X.520
1203 postalAddress ATTRIBUTE ::= {
1204     WITH SYNTAX SEQUENCE SIZE (1..6) OF DirectoryString { 30 }
1205     ID          id-at-postalAddress }
1206
1207 -- pseudonym from (forthcoming) X.520)
1208 pseudonym ATTRIBUTE ::= {
1209     WITH SYNTAX DirectoryString { ub-name }
1210     ID          id-at-pseudonym }
1211
1212 -- domainComponent from RFC 2247
1213 domainComponent ATTRIBUTE ::= {
1214     WITH SYNTAX IA5String
1215     ID          id-domainComponent }
1216
1217 dateOfBirth ATTRIBUTE ::= {
1218     WITH SYNTAX GeneralizedTime
1219     ID          id-pda-dateOfBirth }
1220
1221 placeOfBirth ATTRIBUTE ::= {
1222     WITH SYNTAX DirectoryString { ub-name }
1223     ID          id-pda-placeOfBirth }
1224
1225 gender ATTRIBUTE ::= {
1226     WITH SYNTAX PrintableString (SIZE(1) ^ FROM("M"|"F"|"m"|"f"))
1227     ID          id-pda-gender }
1228
1229 countryOfCitizenship ATTRIBUTE ::= {
1230     WITH SYNTAX PrintableString (SIZE (2))
1231
1232
1233
1234 Santesson, et al.           Standards Track                    [Page 22]
1235 \f
1236 RFC 3039             Qualified Certificates Profile         January 2001
1237
1238
1239         (CONSTRAINED BY { -- ISO 3166 codes only -- })
1240     ID          id-pda-countryOfCitizenship }
1241
1242 countryOfResidence ATTRIBUTE ::= {
1243     WITH SYNTAX PrintableString (SIZE (2))
1244         (CONSTRAINED BY { -- ISO 3166 codes only -- })
1245     ID          id-pda-countryOfResidence }
1246
1247 -- Private extensions
1248
1249 -- Biometric info extension
1250
1251 biometricInfo  EXTENSION ::= {
1252     SYNTAX             BiometricSyntax
1253     IDENTIFIED BY      id-pe-biometricInfo }
1254
1255 BiometricSyntax ::= SEQUENCE OF BiometricData
1256
1257 BiometricData ::= SEQUENCE {
1258     typeOfBiometricData TypeOfBiometricData,
1259     hashAlgorithm       AlgorithmIdentifier,
1260     biometricDataHash   OCTET STRING,
1261     sourceDataUri       IA5String OPTIONAL,
1262     ... -- For future extensions -- }
1263
1264 TypeOfBiometricData ::= CHOICE {
1265     predefinedBiometricType PredefinedBiometricType,
1266     biometricDataOid        OBJECT IDENTIFIER }
1267
1268 PredefinedBiometricType ::= INTEGER { picture(0),
1269     handwritten-signature(1)} (picture|handwritten-signature,...)
1270
1271 -- QC Statements Extension
1272
1273 qcStatements  EXTENSION ::= {
1274     SYNTAX        QCStatements
1275     IDENTIFIED BY id-pe-qcStatements }
1276
1277 QCStatements ::= SEQUENCE OF QCStatement
1278
1279 QCStatement ::= SEQUENCE {
1280     statementId   QC-STATEMENT.&id({SupportedStatements}),
1281     statementInfo QC-STATEMENT.&Type
1282     ({SupportedStatements}{@statementId}) OPTIONAL }
1283
1284 QC-STATEMENT ::= CLASS {
1285     &id   OBJECT IDENTIFIER UNIQUE,
1286     &Type OPTIONAL }
1287
1288
1289
1290 Santesson, et al.           Standards Track                    [Page 23]
1291 \f
1292 RFC 3039             Qualified Certificates Profile         January 2001
1293
1294
1295 WITH SYNTAX {
1296     [SYNTAX &Type] IDENTIFIED BY &id }
1297
1298 qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation
1299     IDENTIFIED BY id-qcs-pkixQCSyntax-v1}
1300     --  This statement identifies conformance with syntax and
1301     --  semantics defined in this Qualified Certificate profile
1302     --  (Version 1). The SemanticsInformation may optionally contain
1303     --  additional semantics information as specified.
1304
1305 SemanticsInformation ::= SEQUENCE {
1306     semanticsIdentifier         OBJECT IDENTIFIER OPTIONAL,
1307     nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
1308     }(WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
1309       WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
1310
1311 NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName
1312
1313 -- The following information object set is defined to constrain the
1314 -- set of attributes applications are required to recognize as QCSs.
1315 SupportedStatements QC-STATEMENT ::= {
1316     qcStatement-1, ... -- For future extensions -- }
1317
1318 END
1319
1320 B. A Note on Attributes
1321
1322    This document defines several new attributes, both for use in the
1323    subject field of issued certificates and in the
1324    subjectDirectoryAttributes extension.  In the interest of conformity,
1325    they have been defined here using the ASN.1 ATTRIBUTE definition from
1326    RFC 2459, which is sufficient for the purposes of this document, but
1327    greatly simplified in comparison with ISO/ITU's definition.  A
1328    complete definition of these new attributes (including matching
1329    rules), along with object classes to support them in LDAP-accessible
1330    directories, can be found in [PKCS 9].
1331
1332 C. Example Certificate
1333
1334    This section contains the ASN.1 structure, an ASN.1 dump, and the
1335    DER-encoding of a certificate issued in conformance with this
1336    profile.  The example has been developed with the help of the OSS
1337    ASN.1 compiler.  The certificate has the following characteristics:
1338
1339       1.  The certificate is signed with RSA and the SHA-1 hash
1340           algorithm
1341       2.  The issuer's distinguished name is O=GMD - Forschungszentrum
1342           Informationstechnik GmbH; C=DE
1343
1344
1345
1346 Santesson, et al.           Standards Track                    [Page 24]
1347 \f
1348 RFC 3039             Qualified Certificates Profile         January 2001
1349
1350
1351       3.  The subject's distinguished name is CN=Petra M.  Barzin, O=GMD
1352           - Forschungszentrum Informationstechnik GmbH, C=DE
1353       4.  The certificate was issued on May 1, 2000 and will expire on
1354           November 1, 2000
1355       5.  The certificate contains a 1024 bit RSA key
1356       6.  The certificate includes a critical key usage extension
1357           exclusively indicating non-repudiation
1358       7.  The certificate includes a certificate policy identifier
1359           extension indicating the practices and procedures undertaken
1360           by the issuing CA (object identifier 1.3.36.8.1.1).  The
1361           certificate policy object identifier is defined by TeleTrust,
1362           Germany.  It is required to be set in a certificate conformant
1363           to the German digital signature law.
1364       8.  The certificate includes a subject directory attributes
1365           extension containing the following attributes:
1366
1367           surname:               Barzin
1368           given name:            Petra
1369           date of birth:         October, 14th 1971
1370           place of birth:        Darmstadt
1371           country of citizenship:Germany
1372           gender:                Female
1373
1374       9.  The certificate includes a qualified statement private
1375           extension indicating that the naming registration authority's
1376           name as "municipality@darmstadt.de".
1377       10. The certificate includes, in conformance with RFC 2459, an
1378           authority key identifier extension.
1379
1380 C.1 ASN.1 Structure
1381
1382 C.1.1 Extensions
1383
1384    Since extensions are DER-encoded already when placed in the structure
1385    to be signed, they are for clarity shown here in the value notation
1386    defined in [X.680].
1387
1388 C.1.1.1 The subjectDirectoryAttributes extension
1389
1390    petrasSubjDirAttrs AttributesSyntax ::= {
1391        {
1392            type id-pda-countryOfCitizenship,
1393            values {
1394                PrintableString : "DE"
1395            }
1396        },
1397        {
1398            type id-pda-gender,
1399
1400
1401
1402 Santesson, et al.           Standards Track                    [Page 25]
1403 \f
1404 RFC 3039             Qualified Certificates Profile         January 2001
1405
1406
1407            values {
1408                PrintableString : "F"
1409            }
1410        },
1411        {
1412            type id-pda-dateOfBirth,
1413            values {
1414                GeneralizedTime : "197110140000Z"
1415            }
1416        },
1417        {
1418            type id-pda-placeOfBirth,
1419            values {
1420                DirectoryString : utf8String : "Darmstadt"
1421            }
1422        }
1423    }
1424
1425 C.1.1.2 The keyUsage extension
1426
1427    petrasKeyUsage KeyUsage ::= {nonRepudiation}
1428
1429 C.1.1.3 The certificatePolicies extension
1430
1431    petrasCertificatePolicies CertificatePoliciesSyntax ::= {
1432        {
1433            policyIdentifier {1 3 36 8 1 1}
1434        }
1435    }
1436
1437 C.1.1.4 The qcStatements extension
1438
1439    petrasQCStatement QCStatements ::= {
1440        {
1441            statementId   id-qcs-pkixQCSyntax-v1,
1442            statementInfo SemanticsInformation : {
1443                nameRegistrationAuthorities {
1444                    rfc822Name : "municipality@darmstadt.de"
1445                }
1446           }
1447        }
1448    }
1449
1450 C.1.1.5 The authorityKeyIdentifier extension
1451
1452    petrasAKI AuthorityKeyIdentifier ::= {
1453        keyIdentifier '000102030405060708090A0B0C0D0E0FFEDCBA98'H
1454    }
1455
1456
1457
1458 Santesson, et al.           Standards Track                    [Page 26]
1459 \f
1460 RFC 3039             Qualified Certificates Profile         January 2001
1461
1462
1463 C.1.2 The certificate
1464
1465    The signed portion of the certificate is shown here in the value
1466    notation defined in [X.680].  Note that extension values are already
1467    DER encoded in this structure.  Some values has been truncated for
1468    readability purposes.
1469
1470    {
1471      version v3,
1472      serialNumber 1234567890,
1473      signature
1474      {
1475        algorithm { 1 2 840 113549 1 1 5 },
1476        parameters RSAParams : NULL
1477      },
1478      issuer rdnSequence :
1479        {
1480          {
1481            {
1482              type { 2 5 4 6 },
1483              value PrintableString : "DE"
1484            }
1485          },
1486          {
1487            {
1488              type { 2 5 4 10 },
1489              value UTF8String :
1490                "GMD - Forschungszentrum Informationstechnik GmbH"
1491            }
1492          }
1493        },
1494      validity
1495      {
1496        notBefore utcTime : "000501100000Z",
1497        notAfter utcTime : "001101100000Z"
1498      },
1499      subject rdnSequence :
1500        {
1501          {
1502            {
1503              type { 2 5 4 6 },
1504              value PrintableString : "DE"
1505            }
1506          },
1507          {
1508            {
1509              type { 2 5 4 10 },
1510              value UTF8String :
1511
1512
1513
1514 Santesson, et al.           Standards Track                    [Page 27]
1515 \f
1516 RFC 3039             Qualified Certificates Profile         January 2001
1517
1518
1519                "GMD Forschungszentrum Informationstechnik GmbH"
1520            }
1521          },
1522          {
1523            {
1524              type { 2 5 4 4 },
1525              value UTF8String : "Barzin"
1526            },
1527            {
1528              type { 2 5 4 42 },
1529              value UTF8String : "Petra"
1530            }
1531          }
1532        },
1533      subjectPublicKeyInfo
1534      {
1535        algorithm
1536        {
1537          algorithm { 1 2 840 113549 1 1 1 },
1538          parameters RSAParams : NULL
1539        },
1540        subjectPublicKey '00110000 10000001 10000111 00000010 1000 ...'B
1541      },
1542      extensions
1543      {
1544        {
1545          extnId { 2 5 29 9 },  -- subjectDirectoryAttributes
1546          extnValue '305B301006082B06010505070904310413024445300F0 ...'H
1547        },
1548        {
1549          extnId { 2 5 29 15 }, -- keyUsage
1550          critical TRUE,
1551          extnValue '03020640'H
1552        },
1553        {
1554          extnId { 2 5 29 32 }, -- certificatePolicies
1555          extnValue '3009300706052B24080101'H
1556        },
1557        {
1558          extnId { 2 5 29 35 }, -- authorityKeyIdentifier
1559          extnValue '30168014000102030405060708090A0B0C0D0E0FFEDCBA98'H
1560        },
1561        {
1562          extnId { 1 3 6 1 5 5 7 1 3 }, -- qcStatements
1563          extnValue '302B302906082B06010505070B01301D301B81196D756 ...'H
1564        }
1565      }
1566    }
1567
1568
1569
1570 Santesson, et al.           Standards Track                    [Page 28]
1571 \f
1572 RFC 3039             Qualified Certificates Profile         January 2001
1573
1574
1575 C.2 ASN.1 dump
1576
1577    This section contains an ASN.1 dump of the signed portion of the
1578    certificate.  Some values has been truncated for readability
1579    purposes.
1580
1581    TBSCertificate SEQUENCE: tag = [UNIVERSAL 16] constructed;
1582      length = 631
1583      version : tag = [0] constructed; length = 3
1584        Version INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
1585          2
1586      serialNumber CertificateSerialNumber INTEGER: tag = [UNIVERSAL 2]
1587        primitive; length = 4
1588        1234567890
1589      signature AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16]
1590        constructed; length = 13
1591        algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1592          length = 9
1593          { 1 2 840 113549 1 1 5 }
1594        parameters OpenType: NULL: tag = [UNIVERSAL 5] primitive;
1595          length = 0
1596          NULL
1597      issuer Name CHOICE
1598        rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16]
1599          constructed; length = 72
1600          RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
1601            constructed; length = 11
1602            AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
1603              constructed; length = 9
1604              type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1605                length = 3
1606                { 2 5 4 6 }
1607              value OpenType: PrintableString: tag = [UNIVERSAL 19]
1608                primitive; length = 2
1609                "DE"
1610          RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
1611            constructed; length = 57
1612            AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
1613            constructed; length = 55
1614              type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1615                length = 3
1616                { 2 5 4 10 }
1617              value OpenType : UTF8String: tag = [UNIVERSAL 12]
1618                primitive; length = 48
1619                0x474d44202d20466f72736368756e67737a656e7472756d2049...
1620      validity Validity SEQUENCE: tag = [UNIVERSAL 16] constructed;
1621        length = 30
1622        notBefore Time CHOICE
1623
1624
1625
1626 Santesson, et al.           Standards Track                    [Page 29]
1627 \f
1628 RFC 3039             Qualified Certificates Profile         January 2001
1629
1630
1631          utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13
1632            000501100000Z
1633        notAfter Time CHOICE
1634          utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13
1635            001101100000Z
1636      subject Name CHOICE
1637        rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16]
1638          constructed; length = 101
1639          RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
1640            constructed; length = 11
1641            AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
1642              constructed; length = 9
1643              type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1644                length = 3
1645                { 2 5 4 6 }
1646              value OpenType: PrintableString: tag = [UNIVERSAL 19]
1647                primitive; length = 2
1648                "DE"
1649          RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
1650            constructed; length = 55
1651            AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
1652              constructed; length = 53
1653              type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1654                length = 3
1655                { 2 5 4 10 }
1656              value OpenType: UTF8String: tag = [UNIVERSAL 12]
1657                primitive; length = 46
1658                0x474d4420466f72736368756e67737a656e7472756d20496e66...
1659          RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
1660            constructed; length = 29
1661            AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
1662              constructed; length = 13
1663              type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1664                length = 3
1665                { 2 5 4 4 }
1666              value OpenType: UTF8String: tag = [UNIVERSAL 12]
1667                primitive; length = 6
1668                0x4261727a696e
1669            AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
1670              constructed; length = 12
1671              type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1672                length = 3
1673                { 2 5 4 42 }
1674              value OpenType: UTF8String: tag = [UNIVERSAL 12]
1675                primitive; length = 5
1676                0x5065747261
1677      subjectPublicKeyInfo SubjectPublicKeyInfo SEQUENCE: tag =
1678        [UNIVERSAL 16] constructed; length = 157
1679
1680
1681
1682 Santesson, et al.           Standards Track                    [Page 30]
1683 \f
1684 RFC 3039             Qualified Certificates Profile         January 2001
1685
1686
1687        algorithm AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16]
1688          constructed; length = 13
1689          algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1690            length = 9
1691            { 1 2 840 113549 1 1 1 }
1692          parameters OpenType: NULL: tag = [UNIVERSAL 5] primitive;
1693            length = 0
1694            NULL
1695        subjectPublicKey BIT STRING: tag = [UNIVERSAL 3] primitive;
1696          length = 139
1697          0x0030818702818100b8488400d4b6088be48ead459ca19ec717aaf3d1d...
1698      extensions : tag = [3] constructed; length = 233
1699        Extensions SEQUENCE OF: tag = [UNIVERSAL 16] constructed;
1700          length = 230
1701          Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
1702            length = 100
1703            extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1704              length = 3
1705              { 2 5 29 9 }
1706            extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
1707              length = 93
1708              0x305b301006082b06010505070904310413024445300f06082b060...
1709          Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
1710            length = 14
1711            extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1712              length = 3
1713              { 2 5 29 15 }
1714            critical BOOLEAN: tag = [UNIVERSAL 1] primitive; length = 1
1715              TRUE
1716            extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
1717              length = 4
1718              0x03020640
1719          Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
1720            length = 18
1721            extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1722              length = 3
1723              { 2 5 29 32 }
1724            extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
1725              length = 11
1726              0x3009300706052b24080101
1727          Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
1728            length = 31
1729            extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1730              length = 3
1731              { 2 5 29 35 }
1732            extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
1733              length = 24
1734              0x30168014000102030405060708090a0b0c0d0e0ffedcba98
1735
1736
1737
1738 Santesson, et al.           Standards Track                    [Page 31]
1739 \f
1740 RFC 3039             Qualified Certificates Profile         January 2001
1741
1742
1743          Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
1744            length = 57
1745            extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
1746              length = 8
1747              { 1 3 6 1 5 5 7 1 3 }
1748            extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
1749              length = 45
1750              0x302b302906082b06010505070b01301d301b81196d756e6963697...
1751
1752 C.3 DER-encoding
1753
1754    This section contains the full, DER-encoded certificate, in hex.
1755
1756    3082030E30820277A0030201020204499602D2300D06092A864886F70D010105
1757    05003048310B300906035504061302444531393037060355040A0C30474D4420
1758    2D20466F72736368756E67737A656E7472756D20496E666F726D6174696F6E73
1759    746563686E696B20476D6248301E170D3030303530313130303030305A170D30
1760    30313130313130303030305A3065310B30090603550406130244453137303506
1761    0355040A0C2E474D4420466F72736368756E67737A656E7472756D20496E666F
1762    726D6174696F6E73746563686E696B20476D6248311D300C060355042A0C0550
1763    65747261300D06035504040C064261727A696E30819D300D06092A864886F70D
1764    010101050003818B0030818702818100B8488400D4B6088BE48EAD459CA19EC7
1765    17AAF3D1D4EE3ECCA496128A13597D16CC8B85EB37EFCE110C63B01E684E5CF6
1766    32291EAC60FD153C266EAAC36AD4CEA92319F9BFDD261AD2BFE41EAB4E17FE67
1767    8341EE52D9A0A8B4DEC07B7ACC76762514045CEE9994E0CF37BAE05F8DE33B35
1768    FF98BCE77742CE4B12273BD122137FE9020105A381E93081E630640603551D09
1769    045D305B301006082B06010505070904310413024445300F06082B0601050507
1770    09033103130146301D06082B060105050709013111180F313937313130313430
1771    30303030305A301706082B06010505070902310B0C094461726D737461647430
1772    0E0603551D0F0101FF04040302064030120603551D20040B3009300706052B24
1773    080101301F0603551D23041830168014000102030405060708090A0B0C0D0E0F
1774    FEDCBA98303906082B06010505070103042D302B302906082B06010505070B01
1775    301D301B81196D756E69636970616C697479406461726D73746164742E646530
1776    0D06092A864886F70D01010505000381810048FD14D9AFE961E4321D9AA40CC0
1777    1C12893550CF76FBECBDE448926B0AE6F904AB89E7B5F808666FB007218AC18D
1778    28CE1E2D40FBF8C16B275CBA0547D7885B74059DEC736223368FC1602A510BC1
1779    EB31E39F3967BE6B413D48BC743A0AB19C57FD20F3B393E8FEBD8B05CAA5007D
1780    AD36F9D789AEF636A0AC0F93BCB3711B5907
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794 Santesson, et al.           Standards Track                    [Page 32]
1795 \f
1796 RFC 3039             Qualified Certificates Profile         January 2001
1797
1798
1799 C.4 CA's public RSA key
1800
1801    This section contains the DER-encoded public RSA key of the CA who
1802    signed the example certificate.  It is included with the purpose of
1803    simplifying verifications of the example certificate.
1804
1805    30818902818100ad1f35964b3674c807b9f8a645d2c8174e514b69a4b46a7382
1806    915abbc44eccede914dae8fcc023abcea9c53380e641795cb0dda664b872fc10
1807    9f9bbb852bf42d994f634c681608e388dce240b558513e5b60027bd1a07cef9c
1808    9b6db37c7e1f1abd238eed96e4b669056b260f55e83f14e6027127c9deb3ad18
1809    afcd3f8a5f5bf50203010001
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850 Santesson, et al.           Standards Track                    [Page 33]
1851 \f
1852 RFC 3039             Qualified Certificates Profile         January 2001
1853
1854
1855 Authors' Addresses
1856
1857    Stefan Santesson
1858    AddTrust AB
1859    P.O. Box 465
1860    S-201 24 Malmo
1861    Sweden
1862
1863    EMail: stefan@addtrust.com
1864
1865
1866    Tim Polk
1867    NIST
1868    Building 820, Room 426
1869    Gaithersburg, MD 20899, USA
1870
1871    EMail: wpolk@nist.gov
1872
1873
1874    Petra Barzin
1875    SECUDE - Sicherheitstechnologie Informationssysteme GmbH
1876    Landwehrstrasse 50a
1877    D-64293 Darmstadt
1878    Germany
1879
1880    EMail: barzin@secude.com
1881
1882
1883    Magnus Nystrom
1884    RSA Security AB
1885    Box 10704
1886    S-121 29 Stockholm
1887    Sweden
1888
1889    EMail: magnus@rsasecurity.com
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906 Santesson, et al.           Standards Track                    [Page 34]
1907 \f
1908 RFC 3039             Qualified Certificates Profile         January 2001
1909
1910
1911 Full Copyright Statement
1912
1913    Copyright (C) The Internet Society (2001).  All Rights Reserved.
1914
1915    This document and translations of it may be copied and furnished to
1916    others, and derivative works that comment on or otherwise explain it
1917    or assist in its implementation may be prepared, copied, published
1918    and distributed, in whole or in part, without restriction of any
1919    kind, provided that the above copyright notice and this paragraph are
1920    included on all such copies and derivative works.  However, this
1921    document itself may not be modified in any way, such as by removing
1922    the copyright notice or references to the Internet Society or other
1923    Internet organizations, except as needed for the purpose of
1924    developing Internet standards in which case the procedures for
1925    copyrights defined in the Internet Standards process must be
1926    followed, or as required to translate it into languages other than
1927    English.
1928
1929    The limited permissions granted above are perpetual and will not be
1930    revoked by the Internet Society or its successors or assigns.
1931
1932    This document and the information contained herein is provided on an
1933    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1934    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1935    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1936    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1937    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1938
1939 Acknowledgement
1940
1941    Funding for the RFC Editor function is currently provided by the
1942    Internet Society.
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962 Santesson, et al.           Standards Track                    [Page 35]
1963 \f