Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 31 Jan 2004 11:17:34 -0000

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: Sat, 31 Jan 2004 12:29:43 +0100

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,

/Stefan

Claim:

Consequence:

Anders