Subject: SV: Last Call: 'Qualified Certificates Profile' to Proposed Standard

From: "Stefan Santesson" <[email-masked]>
Date: Sun, 1 Feb 2004 20:15:52 -0000

Its defined in the policy section and we also agreed to clarify this further as part of our response to Denis.
 
I can't further respond your oposition to something the standard isn't doing, providing or claiming.
 
/Stefan

________________________________

Från: Anders Rundgren [mailto:[email-masked]]
Skickat: sö 2/1/2004 8:33
Till: Stefan Santesson; [email-masked]
Ämne: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard

Stefan,

>qcStatement is a mechanism to highlight aspects already defined by policy.
>It is NOT a mechanism to create variations of the same policy.

But there is absolutely nothing in the draft supporting these claims.

Your ETSI posting on qcStatements mentioned a programmatic policy
module which is completely redundant if qcStatements are just
"clarifications" (i.e. repeating things that you can read about in the
CP documents).

>qcStatement is NOT part of path validation.

I never said that.  But IF qcStatements are used for trust differention
regardless if the validator is human or machine, it is indeed
an extra validation procedure, but outside of RFC3280.

>It is a bit late to discuss the existence of this extension since it
>has been defined by RFC 3039 and has been in use for several
>years by now.

This is indeed true, but don't you think that adding your two initial
claims to the draft would create HUGE opposition?

I rather believe that this mechanism is a way for QC CAs to introduce
NEW stuff under a given policy, without having to create a new CA.
This is IMHO pushing CA related problems on relying parties which
does not seem to be a particularly good idea as the latter typically
outnumber the former by 2-6 magnitudes.

Anders
________________________________

Från: [email-masked] genom Anders Rundgren
Skickat: sö 2/1/2004 10:45
Till: Stefan Santesson; [email-masked]
Ämne: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard

Stefan,

qcStatements are from a software point of view equivalent to warranty extensions.

That is, these constructs introduce a mechanism to allow certain issuance
qualities to be variant under a given policy.

This works great assuming that the relying party is a human being,
probably subscribed to the PKIX-list, and who's main passion is
switching between the applications "Certificate Properties" and
www.nudity.com.

However, for those who like me, rather focus on the other part of the
available market (=99.99999%), such mechanisms instead of "increasing
trust", contribute to costs, hassles and limited customer acceptance.

Yes, even security is put at risk as a system that is hard to understand
and manage, no matter how smart it seems to be, is likely to occasionally
be mis-configured, by the maybe not always so smart system administrators.

Anders

----- Original Message -----
From: "Stefan Santesson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Saturday, January 31, 2004 12:38
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard

Your are posting to the wrong list.
There is nothing in the IETF profile that mandates use of qcStatement extension.

/Stefan

________________________________

Från: Anders Rundgren [mailto:[email-masked]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [email-masked]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard

Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard

Anders,

After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.

/Stefan

________________________________

Från: [email-masked] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [email-masked]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard

Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 2 Feb 2004 10:11:28 +0100

Dear list,

Stefan has in a private mail clarified the situation and we are in
agreement that IETF draft does NOT suffer from the deficiency that
I mentioned.

It is rather ETSI's profiling of RFC3039bis that suffers from what
I consider is a "kludge" by [more or less] requiring a particular
"QC detector" mechanism in relying party applications. 

Why ETSI did rather not exploit the policy system for this function? 
Well, that's a rather long and hairy story that run through the
"anders-draft-translation-engine" returns the single line:

                           because the policy system suxx.

Best
Anders R