Subject: Draft for Qualified Certificates

From: Stefan Santesson <[email-masked]>
Date: Tue, 27 Oct 1998 01:10:51 +0100

As a result from the Chicago meeting I have formed a first preliminary
version of an Internet draft for Qualified Certificates.

The ambition is that this draft shall be developed as a PKIX work item and
finally go the standards track.

The need for this specification is called for by the legal and technical
debate concerning digital signatures which are considered legally
compatible with handwritten signatures.

I will just very shortly give a condensed outline of the preliminary
results and last I copy the complete draft.

Condensed outline:
------------------
The draft is based on PKIX part 1, which in the draft is referred to as
RFCxxxx
The draft focus on a harmonized definition on names (issuer and subject).
It also mandate some extensions to be present and critical.

Issuer name:

Issuer name shall form an unmistakable name of the issuer by examining the
present values of the following attributes:
  countryName
  stateOrProvinceName
  organizationName
  commonName

Subject name:

Subject name can be based on a registered name or a pseudonym.
A registered name shall be hold in the attributes surname and givenName
Pseudonyms shall be hold in a newly defined pseudonym attribute

In addition to this the present pseudonym or registered name may be
reflected in the commonName attribute. This represent the subjects name in
a preferred presentation format.

An umistakable name shall be formed by the pseudonym or registered names in
combination with the present values of the following attributes:

  countryName (defines the context of other attributes)
  civicRegistrationNumber (newly defined)
  serialNumber (added to the preferredAttributes list)
  organizationName
  organizationalUnitName
  postalAddress

Other:

Some useful additional attributes are defined (countryOfCitizenship and
countryOfResidence )

The policy extension shall be present and marked critical. The purpose of
the certificate should be defined directly or indirectly by the policy
(including conformance to this profile).

Key usage shall exclusively be marked for non-repudiation.  

Key identifier extension shall be present but shall NOT be marked critical.

--------------------------------------------------------

Below follows the complete draft (preliminary version)
All comments are highly appreciated.

/Stefan

PKIX Working group                                      S.Santesson (SEIS)
Internet Draft                                               
                                                         October 26, 1998
Expires six in months

                     Internet X.509 Public Key Infrastructure

                              Qualified Certificates

                              <draft-ietf-santesson-qc-00.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 list.

1 Introduction

This standard is one part of a family of standards for the X.509 Public Key
Infrastructure (PKI) for the Internet. The standard is based on RFC xxxx,
which defines underlying certificate formats and semantics 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 Certificates,
its functional relations to legal frameworks and the assumptions 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.
- 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 section 2.3
- Indicate a certificate policy consistent with liabilities, practices 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 certificate 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 digital
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 digital
signatures is thus to identify some minimum requirements on certificates
which are qualified to support digital signatures in a context which is
considered to be "functional equivalent" with handwritten signatures. These
requirements may emphasize different aspects of certificate issuance and
maintenance such as the routines for identifying the key holder, revocation
routines, liabilities of key holders and CA:s, accreditation of CA:s and
information content in certificates.

2.3 Statement of purpose

For a certificate to serve the purpose of supporting digital signatures
that are legally compatible with handwritten signatures, it is 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 applicable
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 certificate. 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 signatures 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 profile to
specify any policies or legal aspects that will govern services 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 profile 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.

3.1 Basic Certificate Fields

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 certificate. The
unmistakable name of the issuer MUST be obtained by examining 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 stateOrProvinceName
as stated below.

The geographical information SHALL be consistent with the legal
jurisdiction under which the CA is operating. The geographical information
SHALL be contained in the mandatory countryName attribute value and if
necessary the stateOrProvinceName attribute. If the stateOrProvince
attribute value is relevant for the legal jurisdiction this attribute is
also mandatory.

3.1.2 Subject 

The subject field SHALL contain an unmistakable name of the subject.

Subject name includes the complete set of attributes describing the
identity and other related attributes and privileges of the subject. In
this profile the attributes used to form the subject name are divided into
four groups:

- Registered name attributes; holding the value of the subject's officially 
  registered name.
- Pseudonym attributes; holding the value of the subjects pseudonym.
- Additional identifying attributes; holding the value of attributes which 
  in combination with the real name attributes or the pseudonym attributes 
  forms an unmistakable identifier of the subject.
- Specific attributes; holding the value of attributes and privileges of the 
  subject which has a purpose other than to identify the subject.

If the Pseudonym attribute is used the additional identity attributes
SHOULD be considered to be part of the pseudonym identity, thus not
representing any officially registered identity attributes of the subject.

3.1.2.1 Registered Name Attributes

If the registered name values of a subject are present in a certificate the
surname attribute type SHALL be used to store surnames and the givenName
attribute type SHALL be used to store given names.

The real name of a subject SHALL be represented by names which are
officially registered within the country given by the value of the
mandatory countyName attribute.

If the real name is carried in the givenName and surename attributes the
commonName attribute type SHALL, when present, be used to store the
subjects name in a preferred presentation format commonly used by the
subject. Nicknames and names with spelling other than defined by the
registered name MAY be used.

3.1.2.2 Pseudonym attributes

If a pseudonym name of a subject is present in a certificate the pseudonym
values SHALL be stored using the pseudonym attribute type.

If a pseudonym is carried in the pseudonym attribute the commonName
attribute type SHALL, if present, be used to store the same pseudonym
value. The rationale for this may be to allow applications to access the
subjects name in its preferred presentation format from the commonName
attribute, regardless of whether the subjects name is a pseudonym or a real
name.
 
3.1.2.3 Additional identifying attributes

The unmistakable identifier of a subject SHALL be obtained by combining the
value of the subjects registered name attributes or pseudonym attributes,
with the values of the following attribute types;

countryName
civicRegistrationNumber
serialNumber
organizationName
organizationalUnitName
postalAddress

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

The countryName attribute is mandatory. All other attributes are OPTIONAL
as long as the used set of attributes form an unmistakable name.

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

The civicRegistrationNumber attribute type SHALL, when present, be used to
store an officially registered civic registration number of the subject,
registered within the specified country. This may be a social security
number or other similar type of civic registration number.

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 as an alternative to the
civicRegistrationNumber attribute type to store officially registered values.

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 organizationName value
also is present then the postalAdress attribute value SHALL be associated
with the specified organization.

3.1.2.4 Specific attributes

This section specifies some specific attributes which may be useful in
Qualified Certificates.

The following attribute types are defined

countryOfCitizenship
countryOfResidence

The countryOfCitizenship attribute type SHALL, when present, be used to
hold the subjects country of citizenship. If the subject is a citizen of
more than one country, they MAY all be included in the certificate using
this attribute type.

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

3.2 Certificate Extensions 

3.2.1 Subject Key identifier

The subject key identifier extension SHALL be present but SHALL NOT be
marked critical.

The keyIdentifier is RECOMMENDED to be composed of a four bit type field
with the value 0100 followed by the least significant 60 bits of the SHA-1
hash of the value of the BIT STRING subjectPublicKey.

3.2.2 Certificate Policies

The certificate policies extension SHALL contain at least one certificate
policy which reflects the practices and procedures undertaken by the CA.
The certificate policy extension SHALL be marked critical.

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.

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 critical.

6 References

RFC 2119

RFC xxxx

X.509 version 3

X.520

Appendix A. Security considerations

A.1 Private key policy

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.

Appendix B.  ASN.1 definitions 

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

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

pseudonym ATTRIBUTE
    ..... To be defined

civicRegistrationNumber ATTRIBUTE
    ..... To be defined

countryOfCitizenship ATTRIBUTE
    ..... To be defined

countryOfResidence ATTRIBUTE
    ..... To be defined

ub-serial-number   INTEGER  ::= 64

Appendix C. Author addresses:

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

-------------------------------------------------------------------
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
-------------------------------------------------------------------