RE: Summary RE: Last Call: Qualified Certificates

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Great,

Then we agree to the point that we should keep RFC 3039 as it is with
regard to this extension.

I guess you are free to ask the WG chairs for permission to start a new
work item for those new extensions.

/Stefan
 
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Denis Pinkas
> Sent: den 23 december 2003 16:26
> To: Stefan Santesson; pkix
> Subject: 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
> >
> >
> >
>