RE: QC Declaration

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

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:stefan@xxxxxxxxxxxxxx]
Sent: Tuesday, March 11, 2003 4:49 PM
To: Sharon Boeyen; ietf-pkix@xxxxxxx
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: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

+46-706 443351

_____________________________

Stefan Santesson,  Retrospekt AB

http://www.retrospekt.com

+46-706 443351

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

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