Subject: RE: QC Declaration

From: Sharon Boeyen <[email-masked]>
Date: Wed, 12 Mar 2003 15:19:27 -0500

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.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 4:49 PM
To: Sharon Boeyen; [email-masked]
Subject: RE: QC Declaration

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
"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]
<mailto:[email-masked]> ]

Sent: Tuesday, March 11, 2003 4:06 PM

To: Sharon Boeyen; Sharon Boeyen; [email-masked]

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:[email-masked]
<mailto:[email-masked]> ] 

Sent: Tuesday, March 11, 2003 11:23 AM 

To: Sharon Boeyen; [email-masked] 

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:[email-masked]
<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 <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 

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com <http://www.retrospekt.com/> 
+46-706 443351

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 13 Mar 2003 09:50:17 +0100

Stefan,

I support Sharon's point of view.
No change should be done.

In general, I am *not* convinced that changes really need to be done
to RFC 3039. We need stable documents.

Denis

> 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.
> 
>     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).
> 
>>     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
>>
>>         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.
>>         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
>>
>>
>>>               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
>>>               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]
>>>             The only guidance on the meaning of criticality in RFC
>>>             3280 (section 4.2) that I can find is:
>>>
>>>
>>>
>>>             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
>>>
>>>>                 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
>>>>                 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)
>>>>                 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.
>>>>                 - 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 
>>
>>