I don't want to get off on a non-relevant tangent regarding
criticality, but think I do need to clarify a little bit on the
subject Alt Name extension. If you check 8.3.2.3 (509) you'll find
that the semantics of that extension are such that, if set to
critical, "at least one of the name forms that is present shall be
recognized and processed ...". So if, in your example, the ONLY
name present in subjectAltName extension is the unknown otherName
OID, then you are correct and the certificate shall be considered
invalid. If however, that unknown otherName OID was present AND
and rfc822Name was present - the RP might understand the
rfc822Name and check it against the intended recipient of an
encrypted email for example, and under those circumstances the
certificate would be valid, even though the extension was critical
and there was another nameform in there that was not understood.
I suspect that its probably a bit too soon to profile the kind of
contexts I think you're describing in 3039. I'd prefer to see a
bit more practical use of QCs first so that we have a better
handle on what constitutes a "context". For example, perhaps one
context is with the ETSI qcstatement 1 plus a specific national qc
statement and if both are present in a certificate that some
'authority' (I don't mean a CA here) deems that when that
combination is present the extension shall be set to critical. I'm
not necessarily opposing the idea, just a little uncomfortable
with the proposed timing without significant real world deployment
to guide us with to the appropriate 'contexts'.
Cheers,
Sharon
-----Original Message-----
From: Stefan Santesson [mailto:stefan@xxxxxxxxxxxxxx]
Sent: Tuesday, March 11, 2003 4:06 PM
To: Sharon Boeyen; Sharon Boeyen; ietf-pkix@xxxxxxx
Subject: RE: QC Declaration
Sharon,
Thanks for the clarification.
"Elements of the syntax" really clarifies things.
So it is OK to accept an certificate with a critical policy
extension containing an policy OID that I don't recognize,
because it doesn't define any further syntax of the extension.
The same goes with Extended key usage OIDs.
However. It would not be OK with a critical subjectAltName
containing an unknown other name OID, since this OID would
define further syntax.
By the same reason I would need to understand all present
QCStatements OIDs, because they do the same (define further
syntax).
Let me clarify that I never proposed that the QCStatement must
be critical in all certificates.
I'm just recognizing that it might be a valuable practice
within certain contexts and the fact that some implementers
actually ask for it.
The question is whether any of those contexts can be
identified within RFC 3039, or if they are better placed in
local sub-profiles (Such as ETSI TS 101862), or if they don't
exist in a way that can be standardized in a meaningful way.
/Stefan
At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
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.
-----Original Message----- From: Stefan Santesson
[mailto:stefan@xxxxxxxxxxxxxx] Sent: Tuesday, March 11,
2003 11:23 AM To: Sharon Boeyen; ietf-pkix@xxxxxxx
Subject: RE: QC Declaration
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
<http://www.retrospekt.com/> +46-706 443351
_____________________________ Stefan Santesson,
Retrospekt AB http://www.retrospekt.com
<http://www.retrospekt.com/> +46-706 443351
_____________________________
Stefan Santesson, Retrospekt AB
http://www.retrospekt.com <http://www.retrospekt.com/>
+46-706 443351