Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 24 Jul 2000 13:06:51 +0200

Peter,

I have a feeling that this discussion has not much to do with technicalties.
It will be the *market* that will tell what is right and what is wrong!

I don't think that the guys who sell certs with non-unique/resissued DNs will be very
successful.  And that is what counts seen from my $-perspective.

You and Ed and other firm believers in other models will have to prove
that there is a market for your ideas otherwise you will just find that your
(probably) home-brewed certificates aren't accepted in too many places.

Pardon the flaming tone, but I think that this discussion is purely theoretical
(=totally uninteresting) as long as no representatives from any CAs
have confirmed that they will reuse DNs.  Cowards?  No, pure reality....
Not a single serious CA will reuse DNs! 

Anders

>> Actually the only reason for me requiring that DNs are not reused is to cope with
>> (the highly likely) situation where a user "shows" a newly issued cert containing 
>> a DN/CA that the particular RP already knows about.  It should be a no-brainer
>> (=pure/simple/stupid software algorithm) to conclude that it is the same person. 
>> 
>Which can be done differently: You sign with the old cert and the new cert a doc
>explaining that this belongs to the same person. 

Which requires that the old certs still exists which is not the case if you dropt it somewhere.

>Or, in other words, the
>equivalence will be established explicitely by the only interested party,
>and not implicitely in an error prone way.

In what way (again assuming that the CA "knows" its subjects and do not reissue DNs) 
whould my proposal be error-prone?

Anders

---

From: Paul Koning <[email-masked]>
Date: Mon, 24 Jul 2000 09:32:13 -0400 (EDT)

>>>>> "Anders" == Anders Rundgren <[email-masked]> writes:

 Anders>...
 Anders> Pardon the flaming tone, but I think that this discussion is
 Anders> purely theoretical (=totally uninteresting) as long as no
 Anders> representatives from any CAs have confirmed that they will
 Anders> reuse DNs.  Cowards?  No, pure reality....  Not a single
 Anders> serious CA will reuse DNs!

I don't believe that for a moment.

The only plausible requirement on DNs is that they are unique at a
given point in time.

It is in no way credible that DNs would be unique over all time.
That's like saying DNS hostnames are unique over all time (i.e., once
I pick a name no one else may ever use that name in the future).

To put it differently, I've *never* seen a naming system that
pretended to implement the "unique for all time" restriction.  Numeric
ID systems, sure.  (Consider the UUID in OSF RPC, copied by
Microsoft.)  DNs I've seen tend to consist of the usual combinations
of organization name, personal name, etc.  No sign ever of a
guaranteed not to be reused sequence number or the like that would
cause it to act as you claim.

I could imagine that some CA might want to attempt to create such a
guarantee for some specialized purpose applied to a select set of
names, but to claim that every CA does this for every DN is something
I don't see supported by any evidence I've ever come across.

     paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Jul 2000 10:02:39 -0400

>I don't see supported by any evidence I've ever come across.

Although I rarely find myself agreeing with Anders, I must do so here 
:-).  While the phrase "for all time" may be a bit strong, it is 
reasonable to assume that a CA can maintain records on all the 
subjects they certify for a very long time. I believe some laws that 
have evolved to support the use of digital signatures impose pretty 
strong requirements on CAs to do precisely this.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Jul 2000 23:51:04 +0200

May I draw your attention to the updated QC 05 where the uniqueness 
requirement stated in RFC 2459 (and son of) has been clarified to count for 
the whole lifetime of the CA.

section 2.4 now states:
    "The distinguished name 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."

This is actually nothing new, rather a clarification of the existing 
technical concept of DNs.
An compliant implementation can simply not be based on CA's using the same 
DN for several different entities. It is reasonable to assume that this is 
the intent behind the original X.501 definition of DNs.
    "Distinguished name is originally defined in X.501 [X.501] as a
     representation of a directory name, defined as a construct that
     identifies a particular object from among the set of all objects."

We are not talking about unintentional mistakes here (which always can 
happen) but the concept of operation.

/Stefan

At 10:02 2000-07-24 -0400, Stephen Kent wrote:
>reasonable to assume that a CA can maintain records on all the subjects 
>they certify for a very long time. I believe some laws that have evolved 
>to support the use of digital signatures impose pretty strong requirements 
>on CAs to do precisely this.
>
>Steve

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 26 Jul 2000 08:36:31 +0200

Stefan,

>      identifies a particular object from among the set of all objects."

This is fine with me and solves one of the seven issues I have
posted on July 13 th. So COMMENT 1 is now solved. I re-post the six
other comments, which up to now have not yet been answered:

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

---

From: "Stefan Kelm" <[email-masked]>
Date: Wed, 26 Jul 2000 17:34:25 +0200

Denis,

> I think both options should be mentioned as possible

I wholeheartedly agree with you. The QCStatement, as useful as
it might be, should not be mandatory.

Cheers,

	Stefan.

--------------------------------------------------------
PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de
--------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 27 Jul 2000 17:11:02 +0200

Denis,

Let me first say that I'm glad that you liked the change in QC-05 regarding DN.

Many of the other issues you raise though are things that has been 
discussed in detail and where consensus has been reached in accordance with 
the current wording.

I hope you agree that it is generally would to change a reached consensus 
decision just based on a single "late" comment from someone that didn't 
participate in the discussion when it took place. At least not unless the 
suggested change fix a serious problem that was not known at time of 
original discussion.

That is why I make much resistance here if I don't see that your requests 
means MAJOR improvements or fix SERIOUS and REAL problems.

Generally I think that all your issues, except for the discussion of new 
extensions, could be discussed on the road between proposed to draft 
standard. There is no reason to uphold the RFC process over wordings that 
does not change the syntax of the standard.

I give more specific comments in line;

>SHALL identify the organization responsible for issuing the

I disagree.

The meaning is to avoid organizations from specifying other names than they 
have registered for the organization. I have practical experiences with 
this when name collisions occur caused by organizations using common 
abbreviations or shorter versions of their name.

Typically we would like to avoid names as e.g. "RSV"  and "DSP" unless 
these organizations have registered these names.
What "registered" actually means is not important from a tecnical point of 
view. It is asumed that all organization names are "registered" according 
to local law.

We had a major discussion around this concluding in the current wording. I 
would like to keep it as it is.

>requirements for Qualified Certificates.". This is contradictory.

No I don't think that this is contradictory. The text above is putting 
requirements on the contet of the listed attributes which include the 
geographical attributes

         countryName;
          stateOrProvinceName; and
         localityName;

What we say is that the content of these attributes SHOULD be consistent 
with the legal jurisdiction. This means that it is not in line with this 
requirement to state Sweden as country if the CA is operating under French law.

I think that this is a legitimate requirement of content and fullfilles the 
need you express below.

>The text should be modified to reflect this.

See above.

The text DOES reflect this by saying that the name should be consistent 
with the legal jurisdiction.

>It should be noticed

No. There are organizations that does not sort under a country. This 
standard is not only there for European CA operators.

This has been discussed, consensus has been reached and the issue closed.

>the DN shall be the country where the CA is operating from.

Disagree according to reasons above.

>in the certificate a public statement that explicitly defines this

Clarification: This says nothing about what method to use and this is 
further just part of the "scope section"

This is a EU directive requirement. So I see nothing wrong with it.

>as discussed in Section 2.2 SHOULD be evident through indicated

This means that the policy should indicate that the certificate is a QC. 
I.e. regardless of any QCStatamenet extension information.

>The basic question is the following: How is it possible to know that

By

1) Recognizing the policy OID and understanding that this is a QC; and/or
2) Recognizing a statement included in the QCStatement extension (if present).

>The text from section 2.2. mandates the inclusion of a QC statement.

Absolutely not:
1) Section 2.2 is just a scope section. It does not mandate anything
2) The wording in 2.2. says "assumes"
3) Section 3.2.2 makes it clear that such statement can be evident from a 
policy OID

>I think both options should be mentioned as possible

They are.

Still there is a flaw in your logic with policy OID:s.
IETF will never issue such a policy, and I doubt that ETSI will.
Still, there is nothing that prevents it from being defined but it's use 
may not be as efficient and general as you think.

>defined in 3.2.5, SHOULD also be defined by included certificate

This means that you should not include policy statement in the QCStatements 
ext. that are not also defined by present policies.

Also note that this is a SHOULD requirement.

The reason is that any relying party that doesn't care about QCStatement 
extensions should be fully informed by the policy. This is the fundamentals 
of handling policies in path validation, i.e. that each policy OID 
identifies a complete set of policy requirements.

>Instead I would propose to define a separate extension to support a

I completely disagree.

The QCStatement extension works just like the policy extension. It includes 
OID:s defining the statement (compare with an OID that define a policy). 
This OID can further be combined with some qualifying data.

The criticality bit does not give what you want anyway. It does only make 
sure that the relying party RECOGNIZE the extension. It doesn't even 
guarantee that the relying party recognize any of the information stored in 
the extension.

The criticality bit, when set, makes sure that the relying party knows what 
type of information he ignores, if he choose to ignore it.
If we would follow your logic then there would also be a "problem" with 
many other extensions, e.g. key usage. What if some key usage information 
is regarded as critical and other as informational? Should we then have 
different extensions for different key usages? I doubt it.

I don't think that we should litter the standard with yet another 
extension. The QC Statements ext works just fine.

There was also a big discussion in ETSI on this. Everybody in the ETSI 
discussion (except you) agreed to go forward with the current solution.

>then proof-of-possession becomes unnecessary. Why not say it ?

Well. POP must be performed and what I read in your wordings, you agree to 
that. It seams that you are locked on the idea that POP requires a separate 
protocol and to me that's NOT the case. A signed request, signed with the 
subject private key, also provides POP.

>to determine if they represent the same physical entity cannot be

No you can't say that.

It may be very possible, in cases where the certificate context allows it. 
I.e. If you have a Swedish certificate with Swedish civic registration 
number. Then you can know that the DN represent the same person even if 
some other data is differing.

It's simply dependent on context. This is a security consideration section 
with the purpose of informing implementers of possible security problems 
that they should be aware of in order to avoid them.

I think that in that context the current existing wording is better.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 27 Jul 2000 22:03:10 -0600

>it might be, should not be mandatory.

So do I

But this is no issue since this already is optional in the current profile.

/Stefan

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 28 Jul 2000 10:18:06 +0200

Stefan,

> Let me first say that I'm glad that you liked the change in QC-05 regarding DN.

:-)

> means MAJOR improvements or fix SERIOUS and REAL problems.

I did observed your resistance. :-) However the issues raised are
SERIOUS and REAL.

> would like to keep it as it is.

I disagree as well. Should the organization be registered at the ICC
? At an ISO body like ANSI, AFNOR, DIN, BIS ? At a country specific
registration authority ? Anyway, this will NOT prevent name
collisions as you might think, since anyway the name is only
meaningful for the CA that issues the certificate.

> requirement to state Sweden as country if the CA is operating under French law.

The legal jurisdiction of what ? I think you mean the legal
jurisdiction where the CA is established. If this is the case, then
this depends from the country where the CA is established, hence the
reason to speak of the country where the CA is established and avoid
in a technical specification legal aspects, as indicated above.

> Disagree according to reasons above.

The same for me.

> >I think both options should be mentioned as possible

Fine. In that case we both agree in principle. :-)
 
However, what can be proven from that discussion is that the text is
ambiguous and thus needs to be clarified.

> IETF will never issue such a policy, and I doubt that ETSI will.

You should take a look at a draft document from ETSI called : Policy
Requirements for Certification Service Providers Issuing Qualified
Certificates ETSI STF 155 T1 Draft H 15th July 2000.

In that document on page 8, section 5.2 the text says:

" 5.2 Identification

The identifiers for the Qualified Certificate Policies specified in
the current document are:

a) QCP Public: A Certificate Policy for Qualified Certificates
issued to the public, Editorial note: Object identifier to be added.

c) QCP Public + SSCD: A Certificate Policy for Qualified
Certificates issued to the public, requiring use of secure
signature creation devices. Editorial note: Object identifier to be
added."

So it is apparent that two OIDs from the ETSI arc will be defined,
since this is an ETSI document.

> ext. that are not also defined by present policies.

I still do not understand. Are you thinking of a possible coliision
with PolicyQualifier (that are not used, but would have been the
"natural place" for making extension to policies). This sentence
either needs clarification or should be deleted. 

> extensions should be fully informed by the policy. 

You cannot say that anymore. In version QC-05, the text now says
that the Qualified Certificate Statements extension may be critical
or non-critical. When it is, then the application MUST understand
it.

> This is the fundamentals
> The QCStatement extension works just like the policy extension.

Why didn't you use PolicyQualifier ?

> It includes

I do not share your interpretation of the sentence which is in RFC
2459, i.e. "A certificate using system MUST reject the certificate
if it encounters a critical extension it does not recognize; "

For me it clearly means that the RP must understand the semantics of
the extension.

> is regarded as critical and other as informational? 

This is not the case. The key usage extension, when present is
critical.

> Should we then have

You forgot to answer to that text replacement proposal.

> subject private key, also provides POP.

I think you missed the point. I am not arguing whether a separate
protocol is necessary or not, I say that POP *towards a CA* is
unecessary for keys that have the NR bit set, as soon as "a good
usage of cryptography" is being used at the time the private key is
being used.
 
> It may be very possible, in cases where the certificate context allows it.

How do you know the "context" ? 

> some other data is differing.

There is no specific rule that you can apply to a Swedish
certificate to bear a different semantics of *one* component of the
DN (ie. the Swedish civic registration number, which is the last
component of the name). The same rules apply to all certificates,
hence there is no notion of "context".

Denis