RE: QC Declaration

["Dean Adams" <da@xxxxxxxxxxx>]

Hi David,
	Seems to me that your statement could be said to be the wrong way around?
"Standardise to establish wide adoption of qualified certifcates in
applications".  This seems like an effort to grow a market from a standards
led approach, something that OSI tried and failed.  I'm not at all sure that
QCs have not taken off because of the lack of standards in the area under
discussion here.  Probably much more (in Europe) to do with the legal and
financial liabilities that have to be taken on by QC providers, and by the
fact that as yet there are not the tools and standards that reflect what
happens in the real world with respect to signing (for example, proxy
signing of documents, emails, etc., e.g. by an assistant or other delegated
person).  We have a draft proxy certificate spec for identity
authentication, but not for the more useful (in my opinion)
email/doc/transaction signing.

Don't get me wrong.  I think the whole QC effort (including suggestions like
yours) are laudable, but I'm just not sure if the real blocking issues are
being tackled by standards.  This opens the way for a variety of competing
proprietary approaches and consequent market fragmentation.

As a technical community, we seem to love adding ever more stuff into our
certificates in the belief that this will unlock the market, or we create
more new standards that can or must be complied with, all without facing the
continuing differences between what is in the standards and what is
happening in real life, c.f. the recent discusions on Basic Constraints and
NR (again).

With respect to the particular extension being discussed here
(QCStatatement).  How far are you prepared to go to ensure that an
application can tell if it really is delaing with a QC?  If you will only
check for existence of the extension and whether it is critical, then that
is not enough.  I can issue a certificate with a QCStatatement that
specifies any conditions I want, thus rendering the apparent consistency
useless.  Will the standard also require applications to check for some
exact specification of wording (as is specified in Europe)?   Will
whitespace and/or case be significant?  Can additional statements be tacked
on? etc.

	I wish you luck in your endeavors.
	Dean
____________________________________________________________
Dean Adams               mobile:         +44 (0)7989 385914
Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
49 Whitehall             Office Tel:     +44 (0)20 7451 1490
London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
email: da@xxxxxxxxxxx    Web: http://www.trustis.com
____________________________________________________________

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of David Cross
Sent: 11 March 2003 16:05
To: Stefan Santesson; ietf-pkix@xxxxxxx
Subject: RE: QC Declaration



Stefan:

I agree with your proposal to make QCStatatement a mandatory extension
and also mark as critical.  I believe this is necessary requirement to
see wide adoption of qualified certifcates in applications.  Otherwise,
it is extremely difficult for generic applications to authoritatively
determine if a signature corresponds to a qualified certificate.


David B. Cross



-----Original Message-----
From: Stefan Santesson [mailto:stefan@xxxxxxxxxxxxxx]
Sent: Tuesday, March 11, 2003 5:27 AM
To: ietf-pkix@xxxxxxx


The EU directive introduced a requirement on each CA, issuing QC
(Qualified Certificates), to clearly indicate in these certificate that
they are issued as QC.

ETSI implemented RFC 3039 in relation to the European electronic
signature directive through their Technical Standard (TS 101862)

TS 101862 specified 2 alternative ways to declare a certificate as QC.

1) By inclusion of a QCStatements extension
2) By including a certificate policy identifying this property

Even though solution number 1) is far easier to handle by applications,
since they don't need to recognize specific QC Policies, ETSI didn't
make solution 1) mandatory or even consider making it critical, due to
lack of confidence that clients would widely deploy this solution. ETSI
needed to define a solution that could work even if no one choose to
implement the new extensions provided by RFC 3039.

However, It is not feasible to keep clients updated over time with
different QC policies and even those policies that are regarded
standardized may be updated with change of OID as a result. It would be
devastating if we can't update a QCP because that would force an OID
update and that would render certificates useless because clients
learned to recognize only the old OID. This would be to build in a new
root certificate problem into the platforms.

My observations is that times have changed. I have seen clear
indications that market players want, and even require for
interoperability reasons, that use QCStatements solution is made
mandatory and maybe even critical for QC.

Since both RFC 3039, and TS 101862 are up for revision, it is time to
revisit this issue.

I have some questions and proposals:

- Is there any experiences of this issue outside of Europe. I.e. are
there other legal systems that make use of the same declaration logic as
the EU directive, where the RFC 3039 profile is used fully or partly as
a solution to this issue?

- I would suggest that the QCStatement mechanism is ought to be a
mandatory tool to communicate a Qualified Status. The question is:
    1) whether this will have enough implementation support to succeed?
    2) whether is best specified in RFC 3039 or in local profiles (such
as TS 101862)?
    3) If there could be a clear context defined where criticality could
be allowed or even required?

I would really like feedback from practical experiences from this issue,
as well as constructive proposals.

/Stefan




/Stefan



_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
+46-706 443351