Subject: RE: QC Declaration

From: Sharon Boeyen <[email-masked]>
Date: Tue, 11 Mar 2003 10:56:08 -0500

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:[email-masked]]
Sent: Tuesday, March 11, 2003 8:27 AM
To: [email-masked]
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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Mar 2003 17:22:46 +0100

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

---

From: Sharon Boeyen <[email-masked]>
Date: Tue, 11 Mar 2003 11:37:03 -0500

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:[email-masked]]
Sent: Tuesday, March 11, 2003 11:23 AM
To: Sharon Boeyen; [email-masked]
Subject: RE: QC Declaration

Hi Sharon,

  "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.

/Stefan

Hi Stefan,

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, March 11, 2003 8:27 AM
To: [email-masked]
Subject: QC Declaration

/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

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 12 Mar 2003 06:44:33 +1300

>the requirements of 509, but rather profiles them to a subset.
                                                        ^^^^^^
You misspelled "superset".

Peter.

---

From: Sharon Boeyen <[email-masked]>
Date: Tue, 11 Mar 2003 12:52:16 -0500

Actually its a of both isn't it :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 12:45 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: QC Declaration

                                                        ^^^^^^

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Mar 2003 22:05:31 +0100

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
>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
>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.
>
>critical or non-critical.  If the extension is critical, this means that 
>all statements
>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.
>

---

From: Sharon Boeyen <[email-masked]>
Date: Tue, 11 Mar 2003 16:30:04 -0500

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:[email-masked]]
Sent: Tuesday, March 11, 2003 4:06 PM
To: Sharon Boeyen; Sharon Boeyen; [email-masked]
Subject: RE: QC Declaration

Sharon,

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).

/Stefan

Hi Stefan,

 

-----Original Message-----

Hi Sharon,

  "A certificate using system MUST reject the

certificate

/Stefan

Hi Stefan,

optimum 

the 

this 

important 

in 

extension that 

not, then 

an extension 

the extension.

extension. Note 

in the extension. 

narrower statements can 

want to include many 

the RP should only 

its own 

be different than 

critical is risky. 

compatibility issues.

Cheers,

Sharon

-----Original Message-----

To: [email-masked]

Subject: QC Declaration

issued as QC.

for QC.

revisit this issue.

to this issue?

TS 101862)?

/Stefan

/Stefan

+46-706 443351 

+46-706 443351

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Mar 2003 22:49:28 +0100

Sharon,

The first step for me is to get the mechanics right.

Are you saying that it would have been compliant with X.509 to declare that 
a critical QCStatement (disregarding the current declaration in RFC 3039) 
is valid if I can process at least one of the present statements (similar 
to SubjectAltName).

Not that I claim that it would be a good idea.

/Stefan

At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
>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 
>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
>>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
>>Because of the semantics defined for the extension in RFC 3039, marking 
>>it critical would result in the problems I raised.
>>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Mar 2003 23:56:39 +0100

Thank you Sharon

Now I'm clear about what the situation is.
I'll come back with some reasoning about this issue.

/Stefan

At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:
>It would have been compliant IF the semantics of the extension stated 
>that. However, the semantics of the extension dictate the opposite where 
>ALL statements are critical.
>Sent: Tuesday, March 11, 2003 4:49 PM
>Are you saying that it would have been compliant with X.509 to declare 
>that a critical QCStatement (disregarding the current declaration in RFC 
>3039) is valid if I can process at least one of the present statements 
>(similar to SubjectAltName).
>
>>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
>>containing an policy OID that I don't recognize, because it doesn't 
>>define any further syntax of the extension.
>>Let me clarify that I never proposed that the QCStatement must be 
>>critical in all certificates.
>>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
>>
>>>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
>>>all reasons), however, no RP is permitted to simply ignore the flag. 
>>>Note also that in that
>>>The only guidance on the meaning of criticality in RFC 3280 (section 
>>>4.2) that I can find is:
>>>
>>>
>>>
>>>
>>>It seam vital to agree on this issue before we can make any conclusion 
>>>on QCStatament criticality.
>>>/Stefan