"A certificate using system MUST reject the
certificate
if it encounters a critical extension it does not recognize"
My interpretation is that it is OK to accept a certificate if you
recognize the extension as such. You don't need to understand ALL
information that the extension contains.
It seam vital to agree on this issue before we can make any
conclusion on QCStatament criticality.
/Stefan
At 10:56 2003-03-11 -0500, Sharon Boeyen
wrote:
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
_____________________________
Stefan Santesson, Retrospekt AB
http://www.retrospekt.com
+46-706 443351