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

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 1 Feb 2004 10:45:28 +0100

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