Subject: RE: What is mean by recognizing critical extensions ?

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 7 Jul 2003 14:41:37 -0700

David,
I think you are giving the impression that the criticality flag is an
input into the decision on whether to process an extension - which is it
not. If an application understands an extension, it must process the
contents of the extension, regardless of criticality. Applications which
do not understand the extension may skip processing of an extension
marked as non-critical. That said; the definition of what constitutes to
process the contents is typically vague. Even in you example - I have no
clue what it means to process a registeredID.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Monday, July 07, 2003 12:03 PM
To: Wahaj
Cc: [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?

Wahaj wrote:

> Hi All,
>  
> I need to know if a Certificate has got an extension marked as 
> critical, should the application process it ( By process I mean 
> perform some action & not merely recognizing it). So if an application

> receives a user certificate having SubjectAltName marked as critical 
> and that application don't use or process SubjectAltName then should 
> the application discard or reject the user certificate based on the 
> fact it won't process it and only recognize it OR should it carry on 
> with it because it can recognize this extension.

If an extension is marked critical, the application must process the 
extension or reject the certificate.  For the SubjectAltName extension, 
X.509 states: "If the [SubjectAltName] extension is flagged critical, at

least one of the name forms that is present shall be recognized and 
processed, otherwise the certificate shall be considered invalid."

> As far as CRL extensions are concerned, it is clearly stated that if 
> they are marked as Critical they should be processed, if not the CRL 
> is not valid and is rejected.
>  
> In RFC 3280 in certificate extension section it is stated " A 
> certificate using system MUST reject the certificate if it encounters 
> a critical extension it does not recognize". Now what recognize mean ?

> is it to use it (in other words process it) or merely read it and 
> not processing. I came across three different terms used. Ability to 
> Recognize, Process or Support. What is exactly meant by them. Are they

> same or different ?
>  
> Also it is stated in RFC 3280 that Basic Constaint MUST be set set as 
> critical. So should an application reject such CA certificate if Basic

> Constraint is present but is not set as critical. Same for other 
> extensions ?

No.  This statement is indicating that CAs conforming to RFC 3280 must 
set the BasicConstraints extension to critical.  There is no requirement

for clients to only accept certificates issued by RFC 3280 compliant
CAs.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 08 Jul 2003 10:31:01 -0400

Trevor,

It was not intention to imply that the criticality flag should be used 
in deciding whether to process an extension.  I agree that if you can 
process an extension, then you must do so, whether the extension is 
critical or non-critical.

For most extensions (e.g., BasicConstraints, nameConstraints, 
policyConstraints, keyUsage), the processing requirements are very 
clearly stated.  Processing rules tend to be more vague for extensions 
in which the processing can only be performed by the user application 
and not by the path validation library.  SubjectAltName is one such 
example.  certificatePolicies is another.  The rules for determining the 
set of policies under which a certificate is valid are well specified, 
but processing the extension also means ensuring that the certificate is 
used in accordance with the rules implied by one of the specified 
policies.   For the most part, this can only be accomplished through 
out-of-band means.

In general, I think that the SubjectAltName extension is only relevant 
in an end certificate.  In an intermediate certificate, the subject 
field must contain a non-null name and so the SubjectAltName extension, 
if present, can (and probably should) be non-critical.  I think 
processing subject names means ensuring that one has the right 
certificate.  For intermediate certificates, this is done by comparing 
the subject field to the issuer field in the next certificate.  For the 
end certificate, this means either determining that the subject name or 
one of the SubjectAltNames matches the name the application is 
"expecting" (e.g., finding the sender's e-mail address in the 
certificate when verifying a signed e-mail message) or using one or more 
of the subject names to inform the application's user of the certified 
name so that the user can determine if the identity is correct.  If the 
end certificate contains a null subject name and the application can not 
process any of the names in the SubjectAltName extension, then there is 
no way to determine if the identity is correct.

I wouldn't know how to process a registeredID either.  But, if I 
received a signed message in which the signer's certificate had a null 
subject name and a SubjectAltName extension that only included a 
registeredID, should I accept the certificate?  Is it of any use to know 
that the message was properly signed if the signer's identity has no 
meaning to me?

Dave

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Wed, 9 Jul 2003 22:14:15 -0700

At 10:31 -0400 7/8/03, David A. Cooper wrote:

as we were finishing up the 4th edition sharon boeyen reported to
our group that some implementors were using an interesting
interpretation of "recognizing an extension". apparently
their recognition essentially meant that they recognized the oid and
recognized that the extension was defined but did not process it, i.e
wrote no code to process the extension as defined in the standard. to
counter this specious argument we wrote some additional text for
clause 7

the 3rd edition contains this paragraph

"The
extensions field allows
addition of new fields to the structure without modification to the
ASN.1 definition. An extension field consists of an extension
identifier, a criticality flag, and a canonical encoding of a data
value of an ASN.1 type associated with the identified extension. For
those extensions where ordering of individual extensions within the
SEQUENCE is significant, the specification of those individual
extensions shall include the rules for the significance of the order
therein. When an implementation processing a certificate does not
recognize an extension, if the criticality flag is FALSE, it may
ignore that extension. If the criticality flag is TRUE, unrecognized
extensions shall cause the structure to be considered invalid, i.e. in
a certificate, an unrecognized critical extension would cause
validation of a signature using that certificate to
fail."

the 4th edition has this replacement paragraph (as well as
additional paragraphs)

"The
extensions
field allows addition of new fields to the structure without
modification to the ASN.1 definition. An extension field consists of
an extension identifier, a criticality flag, and an encoding of a data
value of an ASN.1 type associated with the identified extension. For
those extensions where ordering of individual extensions within
the
SEQUENCE is
significant, the specification of those individual extensions shall
include the rules for the significance of the order therein. When an
implementation processing a certificate does not recognize an
extension, if the criticality flag is FALSE, it may ignore that extension. If the criticality
flag is
TRUE,
unrecognized extensions shall cause the structure to be considered
invalid, i.e. in a certificate, an unrecognized critical extension
would cause validation of a signature using that certificate to fail.
When a certificate-using implementation recognizes and is able to
process an extension, then the certificate-using implementation shall
process the extension regardless of the value of the criticality flag.
Note that any extension that is flagged non-critical will cause
inconsistent behaviour between certificate-using systems that will
process the extension and certificate-using systems that do not
recognize the extension and will ignore it."

note the penultimate sentence.

one of the advantages of implementation conformance statements is
that they can be used to determined what a product implemented and
what it did not. i believe it would be useful for the ietf to define
implementation conformance statement pro formas for their
standards

hoyt

Trevor,

It was not intention to imply that the criticality flag should be used
in deciding whether to process an extension.  I agree that if you
can process an extension, then you must do so, whether the extension
is critical or non-critical.

For most extensions (e.g., BasicConstraints, nameConstraints,
policyConstraints, keyUsage), the processing requirements are very
clearly stated.  Processing rules tend to be more vague for
extensions in which the processing can only be performed by the user
application and not by the path validation library.
SubjectAltName is one such example.  certificatePolicies is
another.  The rules for determining the set of policies under
which a certificate is valid are well specified, but processing the
extension also means ensuring that the certificate is used in
accordance with the rules implied by one of the specified
policies.   For the most part, this can only be accomplished
through out-of-band means.

In general, I think that the SubjectAltName extension is only relevant
in an end certificate.  In an intermediate certificate, the
subject field must contain a non-null name and so the SubjectAltName
extension, if present, can (and probably should) be non-critical.
I think processing subject names means ensuring that one has the right
certificate.  For intermediate certificates, this is done by
comparing the subject field to the issuer field in the next
certificate.  For the end certificate, this means either
determining that the subject name or one of the SubjectAltNames
matches the name the application is "expecting" (e.g.,
finding the sender's e-mail address in the certificate when verifying
a signed e-mail message) or using one or more of the subject names to
inform the application's user of the certified name so that the user
can determine if the identity is correct.  If the end certificate
contains a null subject name and the application can not process any
of the names in the SubjectAltName extension, then there is no way to
determine if the identity is correct.

I wouldn't know how to process a registeredID either.  But, if I
received a signed message in which the signer's certificate had a null
subject name and a SubjectAltName extension that only included a
registeredID, should I accept the certificate?  Is it of any use
to know that the message was properly signed if the signer's identity
has no meaning to me?

Dave

Trevor Freeman wrote:

David,

I think you are giving the impression that the criticality flag is
an

input into the decision on whether to process an extension - which is
it

not. If an application understands an extension, it must process
the

contents of the extension, regardless of criticality. Applications
which

do not understand the extension may skip processing of an
extension

marked as non-critical. That said; the definition of what constitutes
to

process the contents is typically vague. Even in you example - I have
no

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 10 Jul 2003 13:55:22 -0700

At 10:14 PM 7/9/2003 -0700, Hoyt L. Kesterson II wrote:

At 10:31 -0400 7/8/03, David A.
Cooper wrote:

as we were finishing up the 4th edition sharon boeyen reported to our
group that some implementors were using an interesting interpretation of
"recognizing an extension". apparently their recognition
essentially meant that they recognized the oid and recognized that the
extension was defined but did not process it, i.e wrote no code to
process the extension as defined in the standard. to counter this
specious argument we wrote some additional text for clause 7

[snip]

the 4th edition has this
replacement paragraph (as well as additional
paragraphs)

[snip]

therein.
When an implementation processing a certificate does not recognize an
extension, if the criticality flag
is
FALSE, it may
ignore that extension. If the criticality flag
is
TRUE, unrecognized
extensions shall cause the structure to be considered invalid, i.e. in a
certificate, an unrecognized critical extension would cause validation of
a signature using that certificate to fail. When a certificate-using
implementation recognizes and is able to process an extension,
then the certificate-using implementation shall process the extension
regardless of the value of the criticality flag. Note that any extension
that is flagged non-critical will cause inconsistent behaviour between
certificate-using systems that will process the extension and
certificate-using systems that do not recognize the extension and will
ignore it."

Indeed.  This clearly implies that non-critical extensions "may
or may not" be processed.

Moreover, additional confusion is engendered by the phrase

"recognizes and is able to process".

Perhaps this is a redundant conjunction, but logically it implies that
"recognizes" and "is able to process" are distinct
conditions (else, why the conjunction?)

Thus, for non-critical extensions, one has THREE cases:

1.  Does not recognize (may or may not validate certificate, up to
implementation)

2.  "Recognizes", but cannot process (same result as in
1.)

3.  Recognizes and CAN process (MUST process to determine
validity.)

If the intent is to use the term "recognizes" to mean "can
process", then the condition "recognizes and can process"
adds to the confusion.

Cheers!  ____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>

Information Operations and Assurance Center

Lawrence Livermore National Laboratory

Livermore, CA 94551-9900

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Thu, 10 Jul 2003 14:59:26 -0700

I believe that this sentence

When a
certificate-using implementation recognizes and is able to
process an extension, then the certificate-using implementation
shall process the extension regardless of the value of the criticality
flag.

means that if an implementation has the code to process an
extension, it must do so. if it doesn't have the code, then it will
not process an extension because it cannot process it. if, in that
case, that extension is flagged critical, then it cannot use the
certificate.

if anyone believe that the text says that an extension doesn't
have to be processed even though there is an ability to process the
extension, i.e. a belief that not being critical means that one can
choose to process it or not, then i will recommend additional text for
the standard to further clarify the meaning for i can see no useful
result from such potential arbitrariness.

hoyt

At 10:14 PM 7/9/2003 -0700, Hoyt L.
Kesterson II wrote:

At 10:31 -0400 7/8/03, David A. Cooper
wrote:

as we were finishing up the 4th edition sharon boeyen reported to our
group that some implementors were using an interesting interpretation
of "recognizing an extension". apparently their recognition
essentially meant that they recognized the oid and recognized that the
extension was defined but did not process it, i.e wrote no code to
process the extension as defined in the standard. to counter this
specious argument we wrote some additional text for clause 7

[snip]

the 4th edition has this replacement
paragraph (as well as additional paragraphs)

[snip]

therein. When an implementation processing a certificate
does not recognize an extension, if the criticality flag
is FALSE, it may ignore that extension. If
the criticality flag is
TRUE, unrecognized
extensions shall cause the structure to be considered invalid, i.e. in
a certificate, an unrecognized critical extension would cause
validation of a signature using that certificate to fail. When a
certificate-using implementation recognizes and is able to
process an extension, then the certificate-using implementation
shall process the extension regardless of the value of the criticality
flag. Note that any extension that is flagged non-critical will cause
inconsistent behaviour between certificate-using systems that will
process the extension and certificate-using systems that do not
recognize the extension and will ignore it."

Indeed.  This clearly implies that
non-critical extensions "may or may not" be processed.

1.  Does not recognize (may or may not validate certificate, up
to implementation)

If the intent is to use the term "recognizes" to mean
"can process", then the condition "recognizes and can
process" adds to the confusion.

Cheers!  ____tony____

Livermore, CA 94551-9900

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 10 Jul 2003 17:18:33 -0700

Hoyt,

I think the "dispute" is over the term
"recognizes".  Hypothetically, an implementation may not
have the code to "process" a given extension, but might claim
to have the code to "recognize" the extension (and thereby hope
to satisfy some extended compliance criteria, if erroneously).

If one defines "recognizes" IFF "possesses the code to
fully process", the dispute disappears.  But then, the
conjunction "recognizes AND is able to process" (highlighted
below) is indeed redundant, and plausibly misleading.

Cheers!  ____tony____

At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:

When a certificate-using
implementation recognizes and is able to process an extension,
then the certificate-using implementation shall process the extension
regardless of the value of the criticality flag.

means that if an implementation has the code to process an extension, it
must do so. if it doesn't have the code, then it will not process an
extension because it cannot process it. if, in that case, that extension
is flagged critical, then it cannot use the certificate.

if anyone believe that the text says that an extension doesn't have to be
processed even though there is an ability to process the extension, i.e.
a belief that not being critical means that one can choose to process it
or not, then i will recommend additional text for the standard to further
clarify the meaning for i can see no useful result from such potential
arbitrariness.

hoyt

Livermore, CA 94551-9900

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Thu, 10 Jul 2003 17:46:38 -0700

valid point. i don't see much value to considering
"recognizes" as meaning i've heard about the extension but
have no ability to process it. this possibly should be addressed in
two places

1) ietf agreed terminology for stating the capabilities of
an implementation

2) a clean-up of both ietf and iso/itu standard
terminology. somewhere i had some additional text that i considered
that stated that the implementation processed the extension according
to the rules specified in the standard (old osi conformance
lingo)

hoyt

Hoyt,

I think the "dispute" is over the term
"recognizes".  Hypothetically, an implementation may
not have the code to "process" a given extension, but might
claim to have the code to "recognize" the extension (and
thereby hope to satisfy some extended compliance criteria, if
erroneously).

Cheers!  ____tony____

When a certificate-using

means that if an implementation has the code to process an extension,
it must do so. if it doesn't have the code, then it will not process
an extension because it cannot process it. if, in that case, that
extension is flagged critical, then it cannot use the certificate.

if anyone believe that the text says that an extension doesn't have to
be processed even though there is an ability to process the extension,
i.e. a belief that not being critical means that one can choose to
process it or not, then i will recommend additional text for the
standard to further clarify the meaning for i can see no useful result
from such potential arbitrariness.

hoyt

Tony Bartoletti 925-422-3881
<[email-masked]>

Livermore, CA 94551-9900

---

From: "todd glassey" <[email-masked]>
Date: Fri, 11 Jul 2003 07:53:17 -0700

Re: What is mean by recognizing critical extensions ?Hoyt, this is an instance where the would MUST is appropriate because what you are referring to is a the compliance model for use and nothing less. 

On a tangent of this, one of the amazing things is that the technical world seems to miss that most implementation's of this high-tech will be SW in nature, and so they will require some form of internal auditing to assure they are in compliance with the standards. In fact it probably would be wise for the IETF to require some 'test component' specification in the standards track to qualify a technology for release as a standard and possibly publish these as a BCP recommendation for validating the PKI environment. 

Not that it, the IETF, should build the toolkit like what OpenGroup does with their Unix qualification suite, but at least the top level of the functional architecture...

Hmmmm. This is also is probably germane to the x509 standards track too.

T
  ----- Original Message ----- 
  From: Hoyt L. Kesterson II 
  To: [email-masked] 
  Sent: Thursday, July 10, 2003 2:59 PM
  Subject: Re: What is mean by recognizing critical extensions ?

   When a certificate-using implementation recognizes and is able to process an extension, then the certificate-using implementation shall process the extension regardless of the value of the criticality flag.

  means that if an implementation has the code to process an extension, it must do so. if it doesn't have the code, then it will not process an extension because it cannot process it. if, in that case, that extension is flagged critical, then it cannot use the certificate.

  if anyone believe that the text says that an extension doesn't have to be processed even though there is an ability to process the extension, i.e. a belief that not being critical means that one can choose to process it or not, then i will recommend additional text for the standard to further clarify the meaning for i can see no useful result from such potential arbitrariness.

     hoyt

      as we were finishing up the 4th edition sharon boeyen reported to our group that some implementors were using an interesting interpretation of "recognizing an extension". apparently their recognition essentially meant that they recognized the oid and recognized that the extension was defined but did not process it, i.e wrote no code to process the extension as defined in the standard. to counter this specious argument we wrote some additional text for clause 7

    [snip]

      the 4th edition has this replacement paragraph (as well as additional paragraphs)

    [snip]

      therein. When an implementation processing a certificate does not recognize an extension, if the criticality flag is FALSE, it may ignore that extension. If the criticality flag is TRUE, unrecognized extensions shall cause the structure to be considered invalid, i.e. in a certificate, an unrecognized critical extension would cause validation of a signature using that certificate to fail. When a certificate-using implementation recognizes and is able to process an extension, then the certificate-using implementation shall process the extension regardless of the value of the criticality flag. Note that any extension that is flagged non-critical will cause inconsistent behaviour between certificate-using systems that will process the extension and certificate-using systems that do not recognize the extension and will ignore it."

    Indeed.  This clearly implies that non-critical extensions "may or may not" be processed.

    Perhaps this is a redundant conjunction, but logically it implies that "recognizes" and "is able to process" are distinct conditions (else, why the conjunction?)

    1.  Does not recognize (may or may not validate certificate, up to implementation)

    2.  "Recognizes", but cannot process (same result as in 1.)

    3.  Recognizes and CAN process (MUST process to determine validity.)

    If the intent is to use the term "recognizes" to mean "can process", then the condition "recognizes and can process" adds to the confusion.

    Cheers!  ____tony____

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Fri, 11 Jul 2003 09:03:20 -0700

todd, "shall" is considered, by the language mavens in
the standards organization, to be stronger than "must" (see
the 2nd meaning in webster).

iso and itu have agreed on a set of language rules. "shall"
is used when the making a statement about an action that is
compulsory. "may" is used to describe an action that is
optional.

note that laws and regulations use "shall"

i must use "shall"

hoyt

Hoyt, this
is an instance where the would MUST is appropriate because what you
are referring to is a the compliance model for use and nothing
less.

On a tangent
of this, one of the amazing things is that the technical world seems
to miss that most implementation's of this high-tech will be SW in
nature, and so they will require some form of internal auditing to
assure they are in compliance with the standards. In fact it probably
would be wise for the IETF to require some 'test component'
specification in the standards track to qualify a technology for
release as a standard and possibly publish these as a BCP
recommendation for validating the PKI environment.

Not that it,
the IETF, should build the toolkit like what OpenGroup does with
their Unix qualification suite, but at least the top level of the
functional architecture...

Hmmmm. This
is also is probably germane to the x509 standards track
too.

T

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

From: Hoyt L. Kesterson
II

To: [email-masked]

Subject: Re: What is mean by recognizing critical
extensions ?

When a

if anyone believe that the text says that an extension
doesn't have to be processed even though there is an ability to
process the extension, i.e. a belief that not being critical means
that one can choose to process it or not, then i will recommend
additional text for the standard to further clarify the meaning for i
can see no useful result from such potential
arbitrariness.

hoyt

[snip]

[snip]

Indeed.  This clearly implies that non-critical
extensions "may or may not" be processed.

Cheers!  ____tony____

Livermore, CA 94551-9900