RE: QC Declaration

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

Hi Stefan,

While I believe that in the longer term certificate policies will be the
optimum 
way to convey the necessary information, I acknowledge that QC Statements is
the 
more popular scheme at present. Therefore I wouldn't have any problem should
this 
extension be mandated in RFC 3039. 

However, forcing its criticality is going too far I believe. There is an
important 
difference between critical and non-critical extensions that we need to keep
in 
mind from the relying party's perspective. If there is a non-critical
extension that 
the RP understands, but that extension includes some elements that it does
not, then 
the RP is free to process the parts it does understand and ignore others. If
an extension 
is critical however, the RP is required to understand ALL elements within
the extension.

Where I think this can become a problem is the content of the QC Statements
extension. Note 
that RFC 3039 and the ETSI profile define DIFFERENT statements for inclusion
in the extension. 
Also additional profiles may add their own local statements and even
narrower statements can 
get added in specific deployment environments. While the cert issuer may
want to include many 
of these statements to enable the cert to be used in various environments,
the RP should only 
be required to understand and process the statements that are appropriate to
its own 
operating environment as dictated by its local security policy (which could
be different than 
that under which the CA operated). Therefore I think requiring it to be
critical is risky. 
Also requiring that it always be critical would have interop/backward
compatibility issues.

Cheers,
Sharon

 


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



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