Subject: I-D ACTION:draft-ietf-pkix-qc-04.txt

From: [email-masked]
Date: Fri, 07 Jul 2000 07:20:51 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Qualified    
                          Certificates Profile
	Author(s)	: S. Santesson, T. Polk, P. Barzin, M. Nystrom
	Filename	: draft-ietf-pkix-qc-04.txt
	Pages		: 33
	Date		: 06-Jul-00
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-qc-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-qc-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Denis <[email-masked]>
Date: Thu, 13 Jul 2000 16:31:54 +0200

Comments on QC-04 (draft-ietf-pkix-qc-04.txt)

A major improvement has been done with the publication of QC-4, since the notion of "unmistakable
identity" has now disappeared . However, the new text still does not solve the issues that have
been raised on that topic.

COMMENT 1

The most important section is section 2.4. (Uniqueness of names) where the word "unique" is not
used anywhere, except in the title). This section says:

In section 4.1.2.6  Subject, RFC 2459 states: "The DN MUST be unique for each subject entity
certified by the one CA as defined by the issuer name field."

In order to make the text unambiguous it is important to say that: "The DN MUST be unique  for
each subject entity certified by the one CA as defined by the issuer name field during the whole
life time of the CA, i.e. two different living human beings cannot have the same DN."

The current text, copied below, does not bring anything really useful for the topic, and could
advantageously be deleted.

In the context of qualified certificates, a distinguished name denotes a set of attribute values
[X.501] which forms a name that is unambiguous within a certain domain that forms either a real
or a virtual DIT (Directory Information Tree)[X.501].  In the case of subject names the domain is
assumed to be at least the issuing domain of the CA.

COMMENT 2

Section 3.1.1. Issuer states:  "The issuer field SHALL identify the organization responsible
for    issuing the certificate, and SHALL include a registered name of the organization".

The basic question is what is the meaning of a "registered" name. Who should be the registration
authority ? Do we have such an authority for registered names in the IETF ? Is this authority
adequate for such a usage ? Instead of trying to answer the question, it makes more sense to omit
the second part of the sentence which leads to the following sentence: "The issuer field SHALL
identify the organization responsible for issuing the certificate".

COMMENT 3

Section 3.1.1. Issuer states:  "The legal jurisdiction for the issuing CA SHOULD be consistent
with the issuer name.". However the  abstract says: "   The goal of this document is to define a
general syntax independent of local legal requirements." and also " It is important to note that
the profile does not define any legal requirements for Qualified Certificates.". This is
contradictory. From the discussions that recently took place in Stockholm, the agreement was to
mandate the inclusion of the country where from the CA is operating. In this way, by indirection,
the country where the CA is established may implement a supervision scheme, if required.

The text should be modified to reflect this. It should be noticed that taking this into
consideration, the first element of a DN for an issuer must then be a country name. This should
be reflected in the text.

Full text proposal replacement for 3.1.1:

3.1.1  Issuer

The issuer field SHALL identify the organization responsible for
issuing the certificate.

The identity of the issuer SHALL be specified using an appropriate
subset of the following attributes:

         domainComponent;
         countryName;
         stateOrProvinceName;
         organizationName;
         localityName; and
         serialNumber.

Additional attributes MAY be present but they SHOULD NOT be necessary to identify the issuing
organization. The first element of the DN shall be the country where the CA is operating from.

COMMENT 4

The text is not consistent when talking about certificate policies and public statements.

In section 2.2. Statement of Purpose, the text says:

"For a certificate to serve the purpose of being a Qualified
Certificate, this profile assumes that the CA will have to include in
the certificate a public statement that explicitly defines this
intent."

In section 3.2.2.Certificate Policies, the text says:

" A statement by the issuer stating the purpose of the certificate as
discussed in Section 2.2 SHOULD be evident through indicated
policies."

The later statement is not that "evident" at all, in particular since from section 2.2. any
certificate policy may be used, provided that it is consistent with the policy for a QC.

The basic question is the following: How is it possible to know that a certificate is a QC ?
There are two possible answers:

a) use a QC statement to tell it (and this "costs" a new extension),
b) use some pre-defined Certificate Policy OID to tell it (and this costs no new extension).

The text from section 2.2. mandates the inclusion of a QC statement. However, all current
software is able to test for the presence of any Certificate Policy OID in a certificate and thus
the current software could easily check for the presence of pre-defined Certificate Policy OIDs
for QCs. The QC statement mandates the use of a new extension, that no one has yet implemented,
both for the construction of the certificate and the checking of a certification path.

Should we really mandate the presence of the QC statement (as being the only way to indicate that
a certificate is a QC) or should we also allow the use of pre-defined Certificate Policy OID
(making the QC statement non mandatory) ?

I think both options should be mentioned as possible

Note: I must recognise that the following text belonging to section 3.2.2 is not understandable
to me:
" In order to enhance path validation based on policy object identifiers any statement related
to  Qualified Certificates, as defined in 3.2.5, SHOULD also be defined by included certificate
policies."

COMMENT 5

Section 3.2.5. Qualified Certificate Statements, defines an extension for inclusion of defined
statements related to Qualified Certificates. However, there is a major problem with the way the
extension is built. It is constructed as:

 QCStatements ::= SEQUENCE OF QCStatement

Since nothing is said in the text about the criticality this extension is, by implication, non
critical. This means that any individual  QCStatement is not mandatory to understand. So unless
an application specifically looks for some pre-defined statement, it will miss the others and is
not required to "understand them. Also remember that only ONE such extension may be present.

In a profile of this document (not a PKIX document) this extension is being used to specify the
maximum amount of money which is permissible for one transaction, this is what is referred in
QC-04 as "a maximum reliance limit for the certificate indicating restrictions on CA's
liability".

The basic question is whether we should have a separate extension for a maximum reliance from a
CA.

If the maximum reliance limit statement is part of the new extension, there is no guarantee that
it will ever be seen or recognized. In principle any QCStatement in a non critical extension may
be ignored by the application.

If the maximum reliance limit statement is in a separate extension marked critical, no
application could miss it, if it is present.

The requirement comes from an annex of the European Directive. The definition of a maximum
reliance limit is optional and it makes sense to have a dedicated extension to support it.

I would thus propose to suppress the following sentence from 3.2.5: "As an example this MAY
include a maximum reliance limit for the certificate indicating restrictions on CA's liability."

Instead I would propose to define a separate extension to support a maximum reliance limit.

COMMENT 6

Section 4, Security considerations. This section has major problems. It uses some arguments to
provide wrong conclusions. The current text is as follows:

" Since the public keys are for public use with legal implications for
involved parties, certain conditions should exist before CAs issues
certificates as Qualified Certificates. The associated private keys
must be unique for the subject, and must be maintained under the
subject's sole control.  That is, a CA should not issue a qualified
certificate if the private key is shared among entities, or the means
to use the private key is not protected against unintended usage.
This implies that the CA must perform proof-of-possession of the
private key. In addition, it implies that the CA have some knowledge
about the subject's cryptographic module."

The text says that a "CA should not issue a qualified certificate if the private key is shared
among entities". This is fine, but the CA has no way to know whether the private key has been
given to someone else. Proof-of-possession of the private key does not solve the issue as well,
since everyone who has been given the private key could provide proof-of-possession.

What is transparent from the text, but not said correctly, is that if a physical device is used,
then it becomes "more difficult" to share the private key. Proposed text full replacement for the
text above:

"The private keys must be maintained under the subject's sole control.  That is, a CA should not
issue a qualified certificate if the means to use the private key is not protected against
unintended usage. It implies that the CA should have some knowledge about the subject's
cryptographic module."

It should be realized also that proof-of-possession is NOT needed at all what using good
cryptography practice. As soon as the identifier of the certificate being used is protected by
the digital signature, then proof-of-possession becomes unnecessary. Why not say it ?

COMMENT 7

Section 4, Security considerations. The current text is as follows:

"Comparing two qualified certificates to determine if they represent
the same physical entity may provide misleading results and should be
performed with care."

This sentence does not help. Replace by:

"Comparing two qualified certificates, that contain different DNs, to determine if they represent

the same physical entity cannot be made."

Denis