QC Declaration

[Stefan Santesson <stefan@xxxxxxxxxxxxxx>]

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