Subject: Comments to Qualified Certificates draft

From: Juergen Walter <[email-masked]>
Date: Thu, 11 Feb 1999 18:32:21 +0100

I would like to add some comments to the QC draft. The topics are the
following

1) Properties of Qualified certificates,
2) CPS and the semantics of name fields,
3) countryName usage,
4) commonName
5) Security Considerations.

Comments 1),2),4) are more or less editorial, while comments 3), 5) are
more general.

1) Properties of Qualified Certificates

"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 identity based on a pseudonym name or a
   real name of the subject.
   - Exclusively indicates non-repudiation key usage for the certified
   public key.
   - Fully complies with the certificate profile defined in RFC 2459"
[PKIX-QC]

The last three properties should be replaced by 
   - Fully complies with the certificate profile defined in RFC 2459 and
chapter 3 of    this document.

The profile of Qualified Certificates is defined in chapter 3 of
[PKIX-QC]. The fourth and fifth property do not cover the profile given
in chapter 3 completely.

The security requirements defined in chapter 4 should be linked
explicitly. Therefore the following property should be added:

   - Issued by a CA in compliance with reasonable securitity measures
following the security considerations in chapter 4.

2) CPS and the semantics of name fields
(subsection 3.1.1, last paragraph)

"It should be noted, however, that a relying party MAY have to consult
identified certificate policies and/or the issuer's CPS, in order to
determine semantics of name fields and legal jurisdiction." [PKIX-QC]

This paragraph should be moved to the introduction of chapter 3. Not
only the Issuer field (subsection 3.1.1) contains name fields but also
some of the remaining sections of chapter 3 contain name fields (e. g.
3.2.1. Subject Alternative Name). Then in addition, "name field" may be
replaced by "a particullary field" because this note applies to other
fields like placeOfBirth as well. So, "The manner in which the date of
birth is associated with the subject is outside the scope of this
document." may be avoidable. Such phrases can be found in various
sections.

3) countryName usage

The field countryName is defined in subsection 3.1.2 and 3.2.1
respectively. At a first glance, it is a field associated to the
subject. But [PKIX-QC] says about usage in both subsections:

"The countryName attribute value specifies a general context in which
other attributes are to be understood. 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." (*)

I am confused. [PKIX-QC] says "The givenName and surname attribute types
SHALL, if present, contain the registered name of the subject, depending
on the laws under which the CA prepares the certificate." Either this
contradicts the countryName usage specification (*) or the draft allows
that the general context (whatever this means) of other subject´s
attributes differ from which of the givenName and surname attribute. By
the way, there is a difference in meaning between "prepare" and "issue",
isn´t it?

The countryName usage (*) should be replaced by the following:

- The countryName attribute value contained in the ISSUER field
specifies a general context in which other attributes are to be
understood. It should be noted that, the optional attributeSemantics
value may specify variations for attributes contained in the
PersonalData field.

- The countryName attribute value contained in the SUBJECT field SHALL
match one of subject´s countryOfCitizenship or countryOfResidence. The
value may be chosen by subject´s or CA´s preference.

- The countryName attribute contained in the PersonalData field SHALL if
present coincide with the value in the SUBJECT field.

Have I overseen some discussion about the countryName usage? Why should
a countryName different from subject´s countryOfCitizenship or
countryOfResidence have any relevance in Qualified Certificates?

3) commonName

In the 7th paragraph of subsection 3.1.2 [PKIX-QC]

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

should be replaced by

"To understand the nature of the name presented in commonName, complying
applications may have to examine present values of the givenName and
surname attributes contained in the personal data field of the
subjectAltName extension if necessary."

The phrase applies to "Choice I" of subject field definition. Then the
fields givenName and surname are absent in the subject field even if
they may present in the PersonalData record of the subjectAltName field.
The conjunction "and if ..." is therefore misleading in the original
phrase.

4) Security Considerations

[PKIX-QC, chapter 4] "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."

How could the relying party do this? This topic should be reformulated
in the following sense. On the one hand there are security requirements
according to the personal security environment; on the other hand there
are security requirements for certificate path validation.

I hope it helps.

Juergen

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 1999 09:48:53 +0100

Comments in line.

At 10:49 AM 2/18/99 +0100, Anders Rundgren wrote:
>--- Message on the SEIS mailing list ([email-masked])
>
>Hi,
> >The subject field SHALL include one of the following choices of sets of
mandatory attributes:
>     >Choice  I:  countryName commonName
>     >Choice II:  countryName givenName surname
>      snip..
>   >The countryName attribute value specifies a general context in which
other attributes are to be
>   >understood. 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.
>
>To me, this loose specification makes countryName redundant.  The issuer
domain should
>be enough to know how to interpret attributes. SUBJECT countryName just
adds confusion unless
>it denotes citizenship or residence.  None of the latter should affect
interpretation though.

The CountryName attribute is optional. If you find it redundant, then leave
it out. There are on the other hand many certificates that do use this
attribute so I would not prevent it from being used.

>
>A completely other comment regarding the sample certificate.  The sample
is in my opinion not
>very typical.  It contains birth data and gender.  I would say that for
e-commerce this kind
>of data is undesirable.   I believe that in reality dnQalifier of the CA
or the subject organization
>is what we will see.  For employment certificates birth, sex, and
nationality are of no interest.  
>This is established by other means (in the cases you really care) and
stored somewhere else.
>For personal ID-cards organization and role is of no interest.
>So my question is: What kind of use do you anticipate that your
>sample certificate would have?  This is a little bit of track but unless
you go into apps it
>is hard to have opinions about attributes, interpretations etc.
Suggestion: Make a few
>more samples for different purposes.
>

The purpose of the example certificate is only to show an example of how
the profile may be implemented. It does NOT imply that the present
attributes SHALL be present in any speciffic application.

>On a physical card personal data may be of interest to establish the
connection between the person and
>the card/certificate.  But what is inside the certificate, is a different
story.

I guess I lost you here.

>Just my 2 öres.
(What does this mean???? ;-) )

>
>Anders Rundgren
>Senior Internet e-commerce Architect
>
>

/Stefan
-------------------------------------------------------------------
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: "Bob Jueneman" <[email-masked]>
Date: Fri, 19 Feb 1999 14:24:27 -0700

>On "given name, initials..." does that imply that given name is the
first given name and initials are the starting letter of the
subsequent given names?  If so, that's not the right definition.  Many
people use a given name other than their first name as the name by
which they are known, so that their full name looks like "G. Paul
Koning".  Insisting on the first name being given in full is not
correct.

	paul

And don't forget Harry S (no period) Truman.  Not all single characters are
initials.

Likewise, I don't know what you do about Thai and other languages that don't use
a space as a delimiter between words.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Feb 1999 12:28:16 +0100

This sound reasonable.

Could you help me suggest what we should put into the draft.
Surname or GivenName as mandatory attribute for registered name in CHOICE II.

It doesn't seem that you all have the same opinion here. My knowledge here
is unfortunately very limited.

We should though keep in mind that CHOICE I (commonName) also may be used
for any name form.

/Stefan

At 02:11 PM 2/19/99 -0500, Paul Koning wrote:
> >> Hi, >The subject field SHALL include one of the following choices
> >> of sets of
> > mandatory attributes:
> >> >Choice I: countryName commonName >Choice II: countryName
> >> givenName surname
>
> > One other comment.  Individuals with a single name, usually
> > rendered as a surname, are fairly common in Indonesia - and
> > possibly some other countries as well.  X.402 section
> > 18.3.12 defines a personal name with surname mandatory and
> > the other three subfields (given name, initials, and
> > generation) optional.  I believe that the Indonesian
> > situation is the reason why, and that that definition is
> > correct.
>
>Yes, the point that insisting on two part names is wrong has been made 
>before.  (It's discouraging that apparently that was ignored...)
>
>It seems more logical to consider the single name a given name (since
>that's what it is) but what the heck.
>