Subject: Qualified Certificates and the 43:d IETF Meeting

From: Stefan Santesson <[email-masked]>
Date: Tue, 01 Dec 1998 18:03:59 +0100

All,

All,

The editorial team for the Quilified Certificates draft has worked since
Chicago to prepare a first draft until the Orlando meeting. Some new
changes are that the subject field now only contains well known attributes
while more specific identity information is specified in a new
datastructure stored in the subjectAltName extension. This proposal is not
yet stable but comments are welcome if this approach is good or bad.

This draft, and whether it should be adopted as a PKIX work item will be
discussed in Orlando. On the meeting we will present the satus and the
rationales behind this draft.

An official first draft will be issued after the Orlando meeting. The draft
attached below is a preliminary version.

/Stefan

PKIX Working Group                                   S. Santesson (SEIS)
Internet Draft                                            W. Polk (NIST)
                                                        A. Berger  (GMD)

expires in six months                                  November xx, 1998

                Internet X.509 Public Key Infrastructure

                         Qualified Certificates

                    <draft-ietf-santesson-qc-01.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

   This Internet-Draft forms a certificate profile for Qualified
   Certificates, based on RFCxxxx, for use in the Internet. In this
   document the term Qualified Certificate is used to describe a
   certificate which is aimed to support digital signatures in a context
   which is considered functionally equivalent to the use of handwritten
   signatures.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   Please send comments on this document to the [email-masked] mail

Santesson, Polk, Berger                                         [Page 1]

INTERNET DRAFT                                         November xx, 1998

   list.

Santesson, Polk, Berger                                          [Page 2]

INTERNET DRAFT                                         November xx, 1998

   1  Introduction ................................................    4
   2  Requirements and Assumptions ................................    4
   2.1  Properties ................................................    5
   2.2  Legal Framework ...........................................    5
   2.3  Statement of Purpose ......................................    6
   2.4  Policy Issues .............................................    6
   3  Certificate and Certificate Extensions Profile ..............    6
   3.1  Basic Certificate Fields ..................................    7
   3.1.1  Issuer ..................................................    7
   3.1.2  Subject .................................................    7
   3.2  Certificate Extensions ....................................    9
   3.2.1  Subject Alternative extension ...........................    9
   3.2.2  Certificate Policies ....................................   10
   3.2.3  Key Usage ...............................................   10
   4  References ..................................................   10
   5  Intellectual Property Rights ................................   11
   6  Security Considerations .....................................   11
   Appendix A.  ASN.1 definitions .................................   12
   Appendix B.  Author Addresses ..................................   13
   Appendix C.  Full Copyright Statement ..........................   13

Santesson, Polk, Berger                                         [Page 3]

INTERNET DRAFT                                         November xx, 1998

1  Introduction

   This standard is one part of a family of standards for the X.509 Pub-
   lic Key Infrastructure (PKI) for the Internet. The standard is based
   on RFC xxxx, which defines underlying certificate formats and seman-
   tics needed for full implementation of this standard.

   The standard profiles the format and semantics for a specific type of
   certificates named Qualified Certificates. The term Qualified Certi-
   ficates, its functional relations to legal frameworks and the assump-
   tions that affects the scope of this document are defined in section
   2.

   Section 3 defines requirements on information content in Qualified
   Certificates.

   In Appendix A some security considerations are discussed in order to
   clarify the security context in which Qualified Certificates are
   assumed to be utilized.

   Finally Appendix B contains all relevant ASN.1 structures which are
   not already defined in RFCxxxx.

2  Requirements and Assumptions

   The term Qualified Certificates is defined in this section with the
   only purpose to clarify the scope of this standard. The actual
   mechanisms that will decide whether a certificate should or should
   not be considered qualified to meet this definition or whether this
   definition is relevant for a particular certificate or service, are
   outside the scope of this standard.

   In this context the term Qualified Certificate defines a certificate
   which has the properties defined in section 2.1, fall within the
   legal assumptions in section 2.2, and have the primary purpose of
   identifying a person with high level of assurance in non-repudiation
   services, which may protect considerable values.

   Harmonization in the field of Qualified Certificates is essential
   within several aspects that falls outside the scope of RFCxxxx. The
   most important aspects that affects the scope of this specification
   are:

   - Definition of names and identity information in order to identify
   the associated subject in a uniform way.
   - Definition of information which identifies the jurisdiction under
   which the CA operates when issuing a particular certificate.
   - Definition of key usage extension usage for Qualified Certificates.

Santesson, Polk, Berger                                         [Page 4]

INTERNET DRAFT                                         November xx, 1998

   - Requirements for critical extensions.

2.1  Properties

   A Qualified Certificate as defined in this standard is assumed to
   have the following properties:

   - Issued by a CA that makes a public statement that the certificate
   serves the purpose of a Qualified Certificate, as discussed in sec-
   tion 2.3
   - Indicate a certificate policy consistent with liabilities, prac-
   tices and procedures undertaken by the CA, as discussed in 2.4
   - Be issued to a natural person (living human being).
   - Contain an unmistakable name of the subject or an unmistakable
   pseudonym identified as such.
   - Exclusively indicates non-repudiation key usage for the certified
   public key.
   - Fully complies with the certificate profile defined in RFCxxxx

2.2  Legal framework

   The evidence value and thereby the expected legal status of a digital
   signature is highly dependent on the quality of the signers certifi-
   cate as well as the properties of the signature service used to
   create and verify the signature.

   Current national laws in general covers the area of agreements and
   signatures, regardless of whether they appear in a physical or digi-
   tal context. There is however a great uncertainty how traditional law
   will be applied to the relatively new digital techniques. According
   to the UNCITRAL Model law on Electronic Commerce, a key factor for
   the legal status of digital signatures is whether they are used in a
   context where they are to be considered "functionally equivalent" to
   handwritten signatures.

   A common characteristic for emerging legal frameworks regarding digi-
   tal signatures is thus to identify some minimum requirements on cer-
   tificates which are qualified to support digital signatures in a con-
   text which is considered to be "functional equivalent" with handwrit-
   ten signatures. These requirements may emphasize different aspects of
   certificate issuance and maintenance such as the routines for identi-
   fying the key holder, revocation routines, liabilities of key holders
   and CA:s, accreditation of CA:s and information content in
   certificates..sp

2.3  Statement of Purpose

   For a certificate to serve the purpose of supporting digital signa-
   tures that are legally compatible with handwritten signatures, it is

Santesson, Polk, Berger                                          [Page 5]

INTERNET DRAFT                                         November xx, 1998

   assumed that the CA will have to make a public statement which states
   this purpose, presumably published in a CPS.

   The shape of this statement may depend on the governing law under
   which the CA is operating but in general it is assumed that the CA at
   least will have to include in its statement that the certificate:

   - is aimed to be used for verification of digital signatures in a
   context where they are considered "functional equivalent" to hand
   written signatures and;
   - meets all requirements, according to the law under which the CA is
   operating, necessary to support this "functional equivalence".

   The legal effects of this statement will be dependent on the applica-
   ble governing law under which the CA is operating. Within states with
   no specific regulations concerning digital signatures, the statement
   will only be a declaration of the suitable area of use of the certi-
   ficate. In states where regulations are extensive and specific the
   statement will be a declaration that the certificate complies with
   all these regulations.

   The function of the statement is thus to assist any concerned entity
   in evaluating the risk associated with creating or accepting signa-
   tures based on a particular certificate.

2.4  Policy Issues

   Certain policy aspects defines the context in which the profile is to
   be understood and used. It is however outside the scope of this pro-
   file to specify any policies or legal aspects that will govern ser-
   vices that issues or utilizes certificates according to this profile.

   It is however assumed that the issuing CA will undertake to follow a
   publicly available certificate policy which is consistent with its
   liabilities, practices and procedures.

3  Certificate and Certificate Extensions Profile

   This section defines a profile for Qualified Certificates. The pro-
   file is based on the Internet certificate profile RFCxxxx which in
   turn is based on the X.509 version 3 format. For full implementation
   of this section implementers are REQUIRED to consult the underlying
   formats and semantics defined in RFCxxxx.

   ASN.1 definitions relevant for this section are supplied by RFCxxxx
   except for definition of SupportedAttributes which is extended in
   this standard.  Definition of the extended SupportedAttributes and
   definitions of the added attribute types are supplied in Appendix B.

Santesson, Polk, Berger                                          [Page 6]

INTERNET DRAFT                                         November xx, 1998

3.1  Basic Certificate Fields

   (Need some text here)

3.1.1  Issuer

   The issuer field SHALL contain an unmistakable name of the issuer
   which at least SHALL identify the organization liable for the certi-
   ficate. The unmistakable name of the issuer MUST be obtained by exa-
   mining the present values of the following attribute types;

   countryName stateOrProvinceName organizationName commonName

   Additional attributes MAY be present but they SHALL NOT be necessary
   to identify the issuer.

   The attributes organizationName and countryName are mandatory. All
   other attributes are OPTIONAL with the exception concerning sta-
   teOrProvinceName as stated below.

   The organizationName attribute value SHALL be a registered name of the 
   organisation which is registered within the specified country.

   The geographical information SHALL be consistent with the legal jur-
   isdiction under which the CA is operating. The geographical informa-
   tion SHALL be contained in the mandatory countryName attribute value
   and if necessary the stateOrProvinceName attribute. If the sta-
   teOrProvince attribute value is relevant for the legal jurisdiction
   this attribute is also mandatory.

3.1.2 Subject

   An unmistakable identity (based on registered name or a pseudonym name) 
   SHALL be carried in the subject field and optionally in combination 
   with the personalData field carried in the subjectAltName extension (se 
   3.2.1).

   The subject field SHALL contain a distinguished name of the subject 
   which SHALL include one of the following choices of mandatory 
   attributes;

   Choise  I:  countryName commonName
   Choice II:  countryName givenName surname

   The distinguished name of the subject MAY also be specified by the 
   following attributes;

   serialNumber organizationName organizationalUnitName postalAddress

Santesson, Polk, Berger                                         [Page 7]

INTERNET DRAFT                                         November xx, 1998

   Other attributes may be present but shall not be necessary to 
   distinguish the subject name from other subject names within the issuer 
   domain.

   The countryName attribute value specifies a genaral context in which 
   other attributes, and values in the personalData field, are to be 
   understood. A registered name is thus a name registered within that 
   country and the organization is an organization or a branch office 
   located in that country. The country attribute does not necessarily 
   match the subject's country of citizenship or country of residence, nor 
   does it have to match the country of issuance.

   The commonName attribute value when present, SHALL contain a name of 
   the subject in it's preferred presentation format. Pseudonym, 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 and if necessary, the personal data 
   field in the subjectAltName extension.

   The givenName and surname attribute types SHALL if present, contain the 
   registered name of the subject. These attribute SHALL be present in the 
   subject field if the nameOrPseudonym element is not present in the 
   personal data field in the subjectAltName extension.

   The serialNumber attribute type SHALL, when present, be used to store 
   an identifier of the subject of any type. This MAY be a number 
   appointed by the CA but it MAY also be used to hold a civic 
   registration code (such as a social security number).

   The organizationName attribute type and the organizationalUnitName
   attribute type SHALL, when present, be used to store the name and
   relevant information of an organization with which the subject is
   associated.

   The postalAddress attribute type SHALL, when present, be used to
   store an address with which the subject is associated. If an organ-
   izationName value also is present then the postalAdress attribute
   value SHALL be associated with the specified organization.

Santesson, Polk, Berger                                         [Page 8]

INTERNET DRAFT                                         November xx, 1998

3.2 Certificate Extensions

   (Need text here.)

3.2.1 Subject Alternative name

   This standard defines a new Object Identifer and data structure in the 
   form of a PersonalData field, that is used in the OtherName subfield of 
   the subjectAltName extension.

   If the subjectAltName extension contain this PersonalData field, it MAY 
   be necessary for establishing the unmistakable identity of the subject. 
   In such case the subject field is still required to hold a 
   distinguished name (within issuer domain) as defined in section 3.1.2.

   The PersonalData field contains additional information to establish a
   person's identity according to the following structure.

   PersonalData ::= SEQUENCE {

   nameOrPseudonym       NameOrPseudonym
   dateOfBirth           [0] GeneralizedTime OPTIONAL -- no data below day
   placeOfBirth          [1] DirectoryString OPTIONAL -- used as generally
                                                      -- used in the
                                                      -- country of birth,
                                                      -- usually the city. 
   gender                [2] PrintableString OPTIONAL -- assigned M or F
   postalAddress         [3] DirectoryString OPTIONAL
   civicRegistrationCode [4] DirectoryString OPTIONAL
   countryOfCitizenship  [5] PrintableString OPTIONAL -- similar to
                                                      -- countryName
   countryOfResidence    [6] PrintableString OPTIONAL -- similar to 
                                                      -- countryName
   }

   NameOrPseudonym ::= CHOICE {
           surAndGivenName SEQUENCE {
                   surName DirectoryString,
                   givenName SEQUENCE OF DirectoryString
           },
           pseudoNym       DirectoryString
   }

   Information objects SHALL be consistent with attribute values stored in 
   the subject field.

Santesson, Polk, Berger                                          [Page 9]

INTERNET DRAFT                                         November xx, 1998

   The civicRegistrationCode value SHALL, when present, be used to store 
   an officially registered civic registration number of the subject, 
   registered within the specified country (specified in the subject 
   field). This may be a social security number or other similar type of 
   civic registration number.

   The countryOfCitizenship value SHALL, when present, be used to hold the 
   subjects country of citizenship . If the subject is a citizen of more 
   than one country, only one value is allowed to be present. ??????

   The countryOfResidence value SHALL, when present, hold the value of the 
   country in which the subject is resident.

   The Postal Adress value SHALL, when present, hold the value of an 
   address with which the subject is associated. Not this value SHALL be 
   associated with the subject as a private address even if the 
   postalAdress attribute value in the subject field is associated with an 
   organisation. 

   (More text is needed for other values and the OID shall be specified)

3.2.2 Certificate Policies

   The certificate policies extension SHALL contain at least one certi-
   ficate policy which reflects the practices and procedures undertaken
   by the CA.  The certificate policy extension MAY be marked criti-
   cal.

   A statement by the issuer stating the purpose of the certificate as
   discussed in 2.3 SHOULD be evident through an indicated policy or
   through its associated CPS.

   Conforming applications are REQUIRED to recognize and accept the 
   presented policy OID:s in order to accept a certificate

3.2.3 Key usage extension

   The key usage extension SHALL be present and SHALL exclusively assert
   the key usage nonRepudiation (1). No other key usage values are
   allowed to be asserted. The key usage extension SHALL be marked crit-
   ical.

4 References

   [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
            Requirement Levels", March 1997.

[RFC xxxx] R. Housley, W. Ford, W. Polk, and D.Solo, "Internet
            X.509 Public Key Infrastructure: Certificate and CRL
            Profile", ???? 1998.

Santesson, Polk, Berger                                         [Page 10]

INTERNET DRAFT                                         November xx, 1998

[X.509]  ITU-T Recommendation X.509 (1997 E): Information
            Technology - Open Systems Interconnection - The
            Directory: Authentication Framework, June 1997.

   [X.520]  ITU-T Recommendation X.520: Information
            Technology - Open Systems Interconnection - The
            Directory: Selected Attribute Types, 1993.

5  Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this docu-
   ment.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to per-
   tain to the implementation or use of the technology described in this
   document or the extent to which any license under such rights might
   or might not be available; neither does it represent that it has made
   any effort to identify any such rights. Information on the IETF's
   procedures with respect to rights in standards-track and standards-
   related documentation can be found in BCP-11. Copies of claims of
   rights made available for publication and any assurances of licenses
   to be made available, or the result of an attempt made to obtain a
   general license or permission for the use of such proprietary rights
   by implementors or users of this specification can be obtained from
   the IETF Secretariat.

6  Security Considerations

   The legal value of a digital signature which 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 and
   only after the key holders conscious acceptance of the signed message
   content.

   Since the public keys will be used to verify digital signatures as a
   substitute for handwritten signatures, certain conditions should
   exist before CAs recognize certificates as qualified certificates.
   The signatures must be unique to the signer, and must be generated
   under the signer's sole control.  That is, a CA should not issue a
   qualified certificate if the private key is shared among entities, or
   the signature generation is not performed under the subject's con-
   trol.  This implies the CA must have some knowledge about the
   subject's cryptographic module.

Santesson, Polk, Berger                                         [Page 11]

INTERNET DRAFT                                         November xx, 1998

   In addition, a CA should not issue a certificate with a policy map-
   ping to indicate certificates are qualified certificates unless these
   conditions are met.

   This specification is a profile of RFC XXXX.  The security considera-
   tions section of that document applies to this specification as well.

Appendix A. ASN.1 definitions

   (Insert caveats here.)

   The ASN.1 syntax does not permit the inclusion of type statements in
   the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
   the new UNIVERSAL types in modules using the 1988 syntax.  As a
   result, this module does not conform to either version of the ASN.1
   standard.

   This appendix may be converted into 1988 ASN.1 by replacing the
   defintions for the UNIVERSAL Types with the 1988 catch-all "ANY".

   SupportedAttributes     ATTRIBUTE       ::=     {
                name | commonName | surname | givenName | initials |
                generationQualifier | dnQualifier | countryName |
                localityName | stateOrProvinceName | organizationName |
                organizationalUnitName | title | pkcs9email |
                serialNumber 

   serialNumber ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX printableStringSyntax 
                              (SIZE(1..ub-serial-number))
        ::= {attributeType 5}

   ub-serial-number   INTEGER  ::= 64

   These following attributes don't have to be defined in the last change;
   | pseudonym | civicRegistrationCode |
   countryOfCitizenship | countryOfResidence }

Santesson, Polk, Berger                                         [Page 12]

INTERNET DRAFT                                         November xx, 1998

Appendix B. Author Addresses

   Stefan Santesson
   Accurata Systemsäkerhet AB
   Lotsgatan 27d
   216 42 Malmö
   Sweden
   [email-masked]

   Tim Polk
   NIST
   Building 820, Room 426
   Gaithersburg, MD 20899
   USA
   [email-masked]

   Andreas Berger
   GMD - Forschungszentrum Informationstechnik GmbH
   GMD-TKT, Dolivostrasse 15
   D-64293 Darmstadt
   Germany
   [email-masked]

Appendix C.  Full Copyright Statement

   Copyright (C) The Internet Society (date). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  In addition, the
   ASN.1 modules presented in Appendices A and B may be used in whole or
   in part without inclusion of the copyright notice.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process shall be followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.

Santesson, Polk, Berger                                         [Page 13]

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: "secstan" <[email-masked]>
Date: Wed, 2 Dec 1998 19:58:28 -0000

Stefan,

I still have major concerns over this draft in that the naming attributes
used in the subject and issuer are not those used in conventional directory
"distinguished names".  Whilst I recognise that LDAP / X.500 directories are
only one possible means of distributing certificates, the use of qualified
certificates should not make it difficult to use directories for
distributing certificates.

The changes made has moved in the right direction but more could be done to
facilitate a common approach.

More specifically:

1) In 3.1.2, instead of Choice II using surname and firstname, conventions
could be defined for carrying this information in Common Name
(e.g. CommonName =<firstname> <surname>)

2)The standard attribute dnQualifier could be used instead of serialNumber
(Th attribute "serialNumber is defined in RFC 2256 as being the serial
number of a device).

3) postalAddress is more appropriate as an additional subjectAttribute (see
next comment) rather than a naming attribute.

4) In 3.2.1 it is suggested that the structure PersonalData is added to
SubjectAltName.
This doesn't fit in with the standard syntax which defines this as being
GeneralName
(see PKIX part 1).

The Subject Directory Attributes provides a structure which can be used to
carry the additional information about the subject in a way which fits in
with existing standards.

Hope this helps.

Nick Pope