[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QC Declaration
Hi
Stefan,
Remember first that RFC 3280 is a "profile" of X.509 and it does not
replace the requirements of 509, but rather profiles them to a subset.
X.509
in clause 7 allows unknown elements in non-critical extensions only to be
ignored. However, that is more with respect to the elements in the syntax
itself
(for example in the IDP extension no RP is allowed to ignore the
"onlySomeReasons" element if it is present in the extension because the
extension
can
only be critical. The behaviour of RPs will differ however depending on their
specific capability with respect to that element (some will use the CRL for
the
specified reasons and others will seek a different CRL that covers all reasons),
however, no RP is permitted to simply ignore the flag. Note also that in
that
same
clause, for extensions that can be marked critical or non-critical, a system
that understands the extension is required to process it regardless of the
value
of the criticality flag. It is ONLY systems that do not understand an extension
that can ignore it completely if it is marked non-critical.
For the QC Statements extension, RFC 3039 says "This
extension may be critical or non-critical. If the extension is critical,
this means that all statements
included in
the extension are regarded as critical. "
Because of
the semantics defined for the extension in RFC 3039, marking it critical would
result in the problems I raised.
Hi Sharon,
My interpretation of
criticality does not really match yours.
The only guidance on the
meaning of criticality in RFC 3280 (section 4.2) that I can find is:
"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