Subject: Rename Qualified Certificates?

From: Hans Nilsson <[email-masked]>
Date: Fri, 7 May 1999 08:15:25 +0200

Yesterday I attended a meeting with the European Standards Organization CEN,
where we now are trying to prepare the necessary standardization for
implementing the EU directive on Electronic Signatures. The work in PKIX is
regarded as most relevant in this respect, and will be most likely be used
and referenced a lot. This is also true for the current working draft on
Qualified Certificates, which is very much in line with the requirements in
Annex I of the directive.

However, the term Qualified Certiciates is already being used in the
Directive with a special meaning and definition ("a certifciate that meets
the requirements laid down in Annex I and is provided by a certification
service provider that fulfills the requirements laid down in annex II").

Although I am partly responsible for "hijacking" the term QC from the
directive and using it for our work, I now realise that this was not a very
good decision, since the EU term also requires that the CA fulfils Annex II.
We thus two honomyms that mean two different things.

I would therefore like to propose that the PKIX term is changed to something
else, and possibly more descriptive. My suggestion is "identity
certificates", but there may be other good suggestions.

Regards

Hans Nilsson
iD2 Technologies

---

From: Arne Nilsson <[email-masked]>
Date: Fri, 7 May 1999 10:30:37 +0200

I agree with Hans Nilsson's suggestion to rename the PKIX Qualified
Certificate. It seems to me that EU plans to stipulate requirements on a
certificates and their issuance for them to qualify as Qualified
Certificates. This is an Certificate Policy issue, rather than a
Certificate profile issue. In the end EU may publish a Qualified
Certificate Certificate Policy under a seperate OID and possibly take some
responsibility for the auditing of CA:s claiming adherance to this policy.

/Arne Nilsson

_____________________________________________________________

Internet mail:	[email-masked]
Physical mail:	Abstracon
		Arne Nilsson
		Fyradalersgatan 9
		S-413 19 Göteborg
		SWEDEN
Tel. & fax no.:	+46 (0)31-82 34 24
Mobile:		+46 (0)707-70 52 44

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 07 May 1999 12:53:00 +0200

Hans,

Thank you for encouraging words, but concerning the naming issue... 
I must say that I'm divided in this question. Let me give some pros and cons.

First, as I view it, there really is no conflict in the meaning and use of the
term "Qualified Certificates".

In the PKIX draft the term "Qualified Certificates" denotes a certificate which
is aimed to support digital signatures which are considered functionally
equivalent with handwritten signatures. To do this it is assumed that the
issuing CA and the certificate has to be in conformance with national law.

The proposed EU-directive defines the term:
"qualified certificate" means a certificate which meets the requirements laid
down in Annex I and is provided by a certification service provider that
fulfills the requirements laid down in Annex II.

Still, as I see it, this is a Qualified Certificate ACCORDING to the
EU-directive. A Qualified Certificate within a different legal jurisdiction
would be something else. I don't think it would be wise by the EU commission to
take the term "Qualified Certificate" and say that THIS IS A CERTIFICATE
ACCORDING TO EUROPEAN LAW".

I believe more in the case where we say that "Qualified Certificates" are
certificates aimed to support electronic signatures which are considered
functionally equivalent with handwritten signatures, and then say that WITHIN
EUROPEAN LAW THIS MEANS CONFORMANCE WITH EU-DIRECTIVE ANNEX I AND ANNEX II.

The PKIX QC draft is ONLY a profile which as far as possible should give all
necessary functionality prescribed by any legal framework. So lets look at
EU-directive Annex I and see what functionality they require:

(I give my comments in line in capital letters)

EU-directive Qualified certificates must contain:
(x)     an indication that the certificate is issued as a qualified
certificate;

PROVIDED BY THE POLICY EXTENSION
(a)     the identification and the country of establishment of the
certification
service provider issuing it; 

PROVIDED BY THE ISSUER FIELD IN COMBINATION WITH THE POLICY OID AND OPTIONALLY
THE QC PROFILE OID

(b)     the name of the holder or a pseudonym which shall be identified as
such;

PROVIDED BOTH IN THE SUBJECT FIELD AND THE PERSONAL DATA FIELD

(c)     provision for a specific attribute of the holder to be included if
relevant, depending on the purpose for which the certificate is intended;

PROVIDED BY THE COMBINATION OF STANDARD X.520 ATTRIBUTES, THE KEY USAGE
EXTENSION AND THE POLICY EXTENSION

(d)     a signature verification data which corresponds to a signature creation
data under the control of the holder; 

THIS IS THE PUBLIC KEY

(e)     beginning and end of the period of validity of the certificate;  

THIS IS STANDARD STUFF

(f)     the identity code of the certificate; 

ALSO STANDARD STUFF

(g)     the advanced electronic signature of the certification service provider
issuing it; 

ALSO STANDARD STUFF

(h)     limitations on the scope of use of the certificate, if applicable; and

PROVIDED BY THE KEY USAGE EXTENSION AND THE POLICY EXTENSION
(i)     limitations on the value of transactions for which the certificate can
be used if applicable. 

PROVIDED BY THE POLICY EXTENSION

-------------------------------------------
My remarks show HOW the PKIX QC profile could be used to meet the requirements
of ANNEX I. There may be other ways and there may be other profiles for
"Qualified Certificates". There may also be other profiles which are profiling
the PKIX QC profile into specific national standards.

I say all this only to show that the PKIX use and the EU directive use of the
term "Qualified Certificates" are NOT in conflict. They are only describing
different aspects of the same thing, the legal and the technical.

BUT ON THE OTHER HAND.....

I can also see the problem IF EU tries to make this term an exclusive European
term tied ONLY to the European legal framework.

If so, I think we have to invent another term with the same meaning, but for
International use.

My candidate to another name, If we find that we have to change it, is:

"ES-Certificates"

... having the meaning of "Electronic Signature Certificates". This is to adopt
to the new trend of naming "legal" signatures as "Electronic signatures" while
letting the technical mechanism defined in X.509, remain as "digital
signatures".

/Stefan

>certificates", but there may be other good suggestions.

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 07 May 1999 08:32:16 -0400

I agree that the name should be changed; however, I really do not like the
one you have proposed.  "Identity certificates" is a commonly used term
meaning that an identity is bound to a public key in a certificate.

Perhaps a merging of the two terms is better: Qualified Identity Certificates.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 14 May 1999 13:17:51 +0200

Regaring name change of PKIX Qualified Certificates...

I'm ready to give my proposal to a final solution to this.

I propose that we throughout the specification define and use the
abbreviation QCP, standing for "Qualified Certificate Profile.

This is the only reasonable solution I have found.

The QCP is a PROFILE for certificates aimed to support digital signatures
that are considered functionally equivalent to handwritten signatures.

There is only one term known to me that is used to denote such certificate,
and that is the term "Qualified Certificate". So I don't want to lose the
close relation to that term.

This is why I believe that QCP is a good "middle way". The "P" clarifies
that this is a technical profile and prevents mixups with any national
regulation or legal framework specifying functional requirements for
Qualified Certificates.

But before I close this I would like to have Stephen Kent's opinion, since
this may effect the charter.

/Stefan

---

From: "Nick Pope" <[email-masked]>
Date: Sun, 16 May 1999 12:53:24 +0100

Stefan,

The problem with using the term qualified is that under the terms of the
European Directive the certificate profile that is in the current
internet-draft does NOT meet all the requirements for qualified certificates
in Annex I.

Also, unless it is issued by a CA which also meets the annex II it cannot
claim to meet the full requirements of qualified electronic signatures which
are equivalent to hand-written signatures under clause 5.1 of the directive.

Thus, using this term is very misleading when related to European
legislation.

I would support Hans Nilsson's recommendation of the term Identity
Certificate.

Nick

Nick Pope

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Stefan Santesson
> Sent: 14 May 1999 12:18
> To: Russ Housley; Hans Nilsson; Stephen Kent
> Cc: [email-masked]
> Subject: Re: Rename Qualified Certificates?
>
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 May 1999 10:00:42 +0200

Nick,

Thank you for sharing your thoughts, but I think you got i a little bit wrong.

But, on the other hand, it is this type of misunderstandings that makes me
think that maybe we should change the name anyway.

>internet-draft does NOT meet all the requirements for qualified certificates

What do you mean by this???

Do you mean that it is NOT possible to construct a Qualified Certificate
according to the directive, using the PKIX profile.

Please tell me in what sense!!!

The PKIX specification is a technical standard for interoperability. It's
purpose it so supply you with tools to understand the information stored in
such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE "QUALIFIED" OR
NOT. 

>are equivalent to hand-written signatures under clause 5.1 of the directive.

Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
It's purpose is NOT to state any functional or other requirements. It's
purpose is only to provide technical interoperability between "Qualified
Certificates". E.g. so that the information put into an Italian "Qualified
Certificate", can be displayed and understood by a German, English or
American software.

>Thus, using this term is very misleading when related to European

Yes, maybe you are right. 
Personally I don't think there is any conflict, but I sure can see the
misunderstandings coming. 

>I would support Hans Nilsson's recommendation of the term Identity

Anything that we can get a consensus around will do for me. I still like
QCP better but maybe a straw poll is the only way to settle this.

As I see it, we have three candidates.

1- Qualified Certificates (no change)
2- QCP (short form for "Qualified Certificates" Profile.
3- Identity Certificates

Steve, can we make a straw poll on this or do you have any other opinion.

/Stefan

---

From: "Nick Pope" <[email-masked]>
Date: Wed, 19 May 1999 10:01:31 +0100

Stefan,

To expand further on my comment regarding the Directive requirements for
Qualified Certificates not being met by the current QC draft. The specific
requirements which I believe ar not met are:

(x)	an indication that the certificate is issued as a qualified certificate;

I consider this include the fact that the certificate is issued by a CA (CSP
in directive terms) which meets the (annex II) requirement of the directive.
Hence, I recognize that this is may be outside the scope of the PKIX work.

(b)	the name of the holder or a pseudonym which shall be identified as such;

I agree that the QC says that it supports pseudonyms.  However, it doesn't
define how it "shall be identified as such".

From discussions with members of the Commission they require this to be
explicit, not through reference to a practice statement.  Hence this
requires a specific extension.

I may have got this wrong, and would very much welcome your views on how
these requirements are met.  However, I do not see how a CSP wanting to meet
these requirements can do the above in a standard way based on the QC draft.
I would not expect the QC draft to require that fields supporting all these
functions are always present, but if it is to claim the title of "qualified"
from the European viewpoint it should define how these functions can be
supported.

I would very happy to see the QC document did define ways of meeting these
requirements.  However, if it doesn't then I would object to the word
"qualified" appearing in the title.  Whether followed by the word "Profile"
or "identity" or whatever.

Independent of the what we call it I would like to know whether it is your
aim to meet the requirements of the Directive in this document, from the
point of view of interoperability as you describe below.

> Thank you for sharing your thoughts, but I think you got i a
What do I have wrong.  That the QC document aims to meet the requirements of
the Directive to support an equivalent to hand-written signatures, or my
understanding of what is supported by the QC document.

...
> such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE "QUALIFIED" OR
I would hope that it facilitates interoperability between systems conforming
to the Directive.  I agree, from the European viewpoint the definition of
what is "qualified" comes from the Directive.

> Certificate", can be displayed and understood by a German, English or
That would be my aim also.  Where the Italian qualfied certificate conforms
to the Directive and the American software follows the QC document.

...

Hope this helps to clarify my concerns.

Nick

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 May 1999 12:59:35 +0200

Nick,

I'll be happy to explain how the PKIX-QC profile can be used.

Comments in-line.

>Hence, I recognize that this is may be outside the scope of the PKIX work.

This is solved by including a policy OID in the policy extension, defining
this property.

The QC-profile says in 3.2.2:
   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.

And section 2.3 says:
   For a certificate to serve the purpose of supporting digital signa-
   tures 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".

We have given this much thought, and my original proposal was to include an
extension including a "qualified statement". This is however impossible to
do on an international level. No one will know exactly what such statement
means unless this is connected to a very specific legal framework.

I guess that this "incorporation by reference" is the best thing we can do
in an international standard, An the way I read the EU directive, there is
nothing that forbid this type information to be indicated by the policy OID.

I must say that I personally have dedicated myself a lot to have this
specific requirement added to the directive. I have personally met Mr
Schlechter at the Commission, talked to him by telephone and sent text
proposals by mail in order to have this very requirement included in the
directive, so I am very much aware of the need for this information which
was forgotten in the first draft.

I just see no other general way to handle this. If you have any suggestions
I'll be happy to hear them.

>define how it "shall be identified as such".

Yes it does.

Section 3.2.1 explicitly defines an attribute for pseudonym names. In fact
the QC-profile give 2 solutions to the problem and any certificate may use
one or both of these.

1) The first possibility is to include the pseudonym in the commonName
attribute in the subject field. In this case the "identified as such" has
to be taken care of by the policy OID (with the same logic as discussed above).

2) The second and more direct possibility is (as mentioned above) to use
the pseudonym attribute in the personalData field (defined in 3.2.1) as
part of the subjects "unmistakable identity"

>requires a specific extension.

Well, this is not how I have interpreted the text in the directive, and not
the impression I have got through my discussions with several "involved"
people, but I may very well be wrong here.

I'm not sure wether is wise to include such policy information in the
certificate. I would rather not see that kind of information there and I
know that Stephen Kent and Warwick have opposed against this type of
"policy" information.

However, this is something that would be technically possible to include if
required by the European community. This is what the PKIX list is for, to
have this kind of debates.

>from the European viewpoint it should define how these functions can be

Since Hans Nilsson, leader of the expert team at EESSI (European Electronic
Signature Standardization Initiative) also have joined the editorial team
of this work, I have hopes that the European community will take the chance
to make this PKIX profile good and successful for all parties involved.   

>or "identity" or whatever.

It is my hope that we will earn the right to carry the name "Qualified"
according to your standards. Anyway, we have to find a name that most
people can agree on.

>point of view of interoperability as you describe below.

Definitely, as long as the requirements can be met by mechanisms that make
sense in an international context. If you need specific European solutions,
specifically tailored for the European community, then that may have to be
solved by some European amendments or in a European profile.

It is my hope though, that such work should not be necessary, but that's
not for me to decide.

>understanding of what is supported by the QC document.

The later. I hope I can convince you that you CAN use the PKIX-QC profile
to form a certificate that meets the requirements from Annex I. If not, I
would like to see through that is does.

>to the Directive and the American software follows the QC document.

That is two different things that can't be compared. The directive is no
technical standard and the QC document is no legal document. I would say
that the Italian certificate has to comply with the directive AND the QC
document in order to achieve full functionality and technical interoperability.

>Hope this helps to clarify my concerns.

Yes id does. Thank you for your views and I hope that we can agree on good
solutions.

/Stefan

---

From: "Nick Pope" <[email-masked]>
Date: Thu, 20 May 1999 13:21:32 +0100

Stefan,

Thanks for your explanation.

I think the main issue is whether this can be indicated by reference to the
CPS or whether it has to be explicit in the certificate.  My understanding
is that the statement "Qualified certificates must contain" implies that it
should be explicit.

Hans, has suggested that we sort out the details of the implication on the
QC draft from the European perspective, outside this list, and then come
back once with have an agreed European understanding.   I'll put together
inital detailed thoughts.

Nick

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: 20 May 1999 12:00
> To: Nick Pope; Hans Nilsson; Stephen Kent
> Cc: [email-masked]
> Subject: RE: Rename Qualified Certificates?
>
>
> Nick,
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 May 1999 09:24:16 -0400

Nick,

I have encountered this issue of putting data of this sort directly into
the cert or incorporating it by reference in UN e-commerce document as
well.  Last year Warwick, Mike Baum, Hoyt Kesterson and I co-authored a
letter to the relevant UN folks urging them to allow incorporation by
reference.  So, I'd suggest we push for that approach in this standard, in
an effort to display solidarity in the technical community about how this
should be done.

Steve

---

From: "Nick Pope" <[email-masked]>
Date: Thu, 20 May 1999 16:27:14 +0100

Steve,

I agree with the aim of not over-loading a certificate.  However, I don't
want to go too far the other way and overload the policy id so that a new
policy id is required for any minor variation on the use certificates within
a common overall policy.

Nick
> From: Stephen Kent [mailto:[email-masked]]
> Sent: 20 May 1999 14:24
> To: Nick Pope
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 May 1999 17:57:49 -0400

Nick,

>policy id is required for any minor variation on the use certificates within

Fair comment.  One might use a new extension, as Bob Junenman suggested,
although when I look at policy qualifiers I see a ready made place to plug
in a range of values for approval authority, currency and max value for
liability, etc.

Steve