[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summary RE: Last Call: Qualified Certificates


Stefan,

Denis,

I understand your request but I don't agree with your conclusion.

I can see the possibilities with a scheme with more tight definition of
criticality since it would enable the ability to force acceptance of a
certain statement while another informative statement could be ignored.

However, I think the cost of providing that capability is too high
compared to both the benefits and the demand for it. And this is not the
only extension where you have the same type of issue.

Similar problem can be associated with:
- Subject and issuer alt name
- Certificate policies
- Extended Key usage

All of these may contain multiple instances of OID defined properties
where I may want to assign different "must recognize" properties.

This is a generic limitation of X.509 extension structure and not unique
for qcStataments.

I do not agree with your interpretation.

The main idea beyond the criticality bit is the following: either it is critical and the RP must understand all the content of the extension, or it is non critical and then the RP is free to ignore if it cannot interpret it.

The QCstatement extension does not allow a mixture on critical and non critical individual QCstatements.

What I am requesting for is :

 1 - to keep the QCStatement extension in RFC 3039 as it is and,
 2 - to define in a new document (which does not superseed RFC 3039)
     two new extensions:
       a) one which is always critical to include critical statements,
          and,
       b) one which is always non-critical to include non-critical
          statements.

Denis

/Stefan



-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
Sent: den 22 december 2003 12:19
To: Stefan Santesson
Subject: Re: Summary RE: Last Call: Qualified Certificates

Stefan,

I have not yet seen your response to my comments.
Here is an additional comment:

RFC 3039 states :

"3.2.5 Qualified Certificate Statements

(...)

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.

      qcStatements  EXTENSION ::= {
          SYNTAX             QCStatements
          IDENTIFIED BY      id-pe-qcStatements }

id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 }

QCStatements ::= SEQUENCE OF QCStatement "


Since at this time this extension has only be used for one statement,
there
is no problem. However, in the future it is desirable to allow to

include

one or more statements, some of them being critical and some other

being

non-critical. This extension is unable to support this feature.

It is impossible to redefine this extension with a new semantics so
thisdefine a  extension has to stay as it is, but there is a need to

allow

this flexibility.

There are two possibilities:

1) define two extensions, one being always critical and the other one
being
always non critical. All critical statements would be in the first
extension
while all non critical statements would be in the other one.

2) define a new extension allowing to mix both critical and non

critical

statements. In case this second option is followed, hereafter is how

such

a
new extension would look like:

"Identity Certificate Statements

This extension may be critical or non-critical. If the extension

is

critical, this means that every statement included in the

extension

and
   individually marked critical MUST be understood.

      icStatements  EXTENSION ::= {
          SYNTAX             QCStatements
          IDENTIFIED BY      id-pe-icStatements }

id-pe-icStatements OBJECT IDENTIFIER ::= { id-pe 4 }

ICStatements ::= SEQUENCE OF ICStatement "

      ICStatement ::= SEQUENCE {
          critical      BOOLEAN DEFAULT FALSE
          statementId   IC-STATEMENT.&Id({SupportedStatements}),
          statementInfo IC-STATEMENT.&Type
          ({SupportedStatements}{@statementId}) OPTIONAL }

SupportedStatements IC-STATEMENT ::= { icStatement-1,...} "


Once again, it makes sense to define a NEW RFC dedicated to "Identity
Certificates for physical persons", but it still does not make sense

to

replace RFC 3039.

Denis