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

From: "Oshman, Dave" <[email-masked]>
Date: Tue, 8 Jul 2003 08:14:27 -0400

Wahaj--
Not sure if anyone has answered this part of your question so here's my
attempt.

Wahaj wrote:

>  
> 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 ?

Regarding this question which leans toward asking if critical extensions
need to be "processed" or only "recognized" along with definitions of
the terms. In section 6.1.4 in 3280, it states:
(o)  Recognize and process any other critical extension present in
      the certificate.  Process any other recognized non-critical
      extension present in the certificate.
So, you do need to "process" all critical extensions. If you recognize
any non-critical extensions, you must "process" them as well. 

Now, the more difficult question is what is meant by "process". I'd say
that "processing" is more or less described in sections 4 & 5 where each
extension is described. For example, the Key Usage extension defined in
4.2.1.3, if recognized, should be processed to verify that the
certificate is being used for the purpose(s) described. E.g. Is the
application attempting to provide a non-repudiation service which
"protects against the signing entity falsely denying some action,
excluding certificate or CRL signing." such as signing off on a purchase
order. If so, the non-repudiation bit in the key usage extension must be
set or else the usage is invalid.

I'd then say that "recognize" means "include processing logic for the
extension". 

I think "support" means a combination of both.

Regards,
Dave Oshman

---

From: Sharon Boeyen <[email-masked]>
Date: Fri, 11 Jul 2003 10:58:57 -0400

Oops, Correction, the text I quoted in my earlier message is from clause 7,
not clause 8. Here is the relevant text from clause 8. Hoyt I wonder if this
is the text you were thinking about?
In a certificate or CRL, an extension is flagged as being either critical or
non-critical. If an extension is flagged critical and a certificate-using
system does not recognize the extension field type or does not implement the
semantics of the extension, then that system shall consider the certificate
invalid. If an extension is flagged non-critical, a certificate-using system
that does not recognize or implement that extension type may process the
remainder of the certificate ignoring the extension. If an extension is
flagged non-critical, a certificate-using system that does recognize the
extension, shall process the extension. Extension type definitions in this
Directory Specification indicate if the extension is always critical, always
non-critical, or if criticality can be decided by the certificate or CRL
issuer. The reason for requiring some extensions to be always non-critical
is to allow certificate-using implementations which do not need to use such
extensions to omit support for them without jeopardizing the ability to
interoperate with all certification authorities.

While on this topic of critical extensions and rejections - I want to be
sure everyone realizes that  the handling is different for CRLs. If the
certificate of interest is listed as revoked on a CRL it is as a minimum
considered revoked regardless of the presence of unrecognized critical
extensions. Here is the relevant text from clause 7.3 of X.509:
 
NOTE 4 - When an implementation processing a certificate revocation list
does not recognize a critical extension in the crlEntryExtensions field, it
shall assume that, at a minimum, the identified certificate has been revoked
and is no longer valid and perform additional actions concerning that
revoked certificate as dictated by local policy. When an implementation does
not recognize a critical extension in the crlExtensions field, it shall
assume that identified certificates have been revoked and are no longer
valid. However in the latter case, since the list may not be complete,
certificates that have not been identified as being revoked cannot be
assumed to be valid. In this case local policy shall dictate the action to
be taken. In any case local policy may dictate actions in addition to and/or
stronger than those stated in this Specification.

I'll stop quoting now (I guess having edited a document does come in handy
for some reasons - at least I can generally locate text when it appears in
the "not most obvious" places :-)
 
 -----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Friday, July 11, 2003 8:43 AM
To: 'Hoyt L. Kesterson II'; [email-masked]
Subject: RE: What is mean by recognizing critical extensions ?

I have no objection to eliminating "recognizes" from the text if it is felt
necessary, but I also want to point out the text that is only a little bit
further down in clause 8
of X.509:
 
A validation engine has two possible actions to take with respect to an
extension:

i)      it can ignore the extension and accept the certificate (all other
things being equal);

ii)     it can process the extension and accept or reject the certificate
depending on the content of the extension and the conditions under which
processing is occuring (e.g. the current values of the path processing
variables).

Some extensions can only be marked critical. In these cases a validation
engine that understands the extension, processes it and acceptance/rejection
of the certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
rejects the certificate.

Some extensions can only be marked non-critical. In these cases a validation
engine that understands the extension processes it and acceptance/rejection
of the certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
accepts the certificate (unless factors other than this extension cause it
to be rejected).

Some extensions can be marked critical or non-critical. In these cases a
validation engine that understands the extension processes it and
acceptance/rejection of the certificate is dependent (at least in part) on
the content of the extension, regardless of the criticality flag. A
validation engine that does not understand the extension accepts the
certificate if the extension is marked non-critical (unless factors other
than this extension cause it to be rejected) and rejects the certificate if
the extension is marked critical.

While I suppose it could be argued that "understands" is not much better
than "recognizes", I think the final paragraph is clearer about what a
validation engine is required to do. 

I think that when we changed all this text the last time, there were some
voices that opposed eliminating "recognizes" from the text because that is
the only term that was used in the 3rd edition. Perhaps there is no longer
support for that position. Note that these changes were a result of defect
report 244 against the 3rd edition text (resolution published in TC 2 for
3rd edition and integrated into 4th edition text).

Sharon

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

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).

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:

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

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Russ Housley <[email-masked]>
Date: Sun, 13 Jul 2003 10:31:18 -0400

Sharon:

The Certificate Issuer CRL Entry Extension seems to be an exception,
which is the reason that I thought it had to be a critical
extension.  If certificate using software were to use the CRL issuer
distinguished name and the serial number associated with such an entry,
then the software would consider the wrong certificate to be
revoked.

Russ

At 10:58 AM 7/11/2003 -0400, Sharon Boeyen wrote:

While
on this topic of critical extensions and rejections - I want to be sure
everyone realizes that  the handling is different for CRLs. If the
certificate of interest is listed as revoked on a CRL it is as a minimum
considered revoked regardless of the presence of unrecognized critical
extensions. Here is the relevant text from clause 7.3 of
X.509:

NOTE 4 – When an
implementation processing a certificate revocation list does not
recognize a critical extension in the
crlEntryExtensions
field, it shall assume that, at a minimum, the identified certificate has
been revoked and is no longer valid and perform additional actions
concerning that revoked certificate as dictated by local policy. When an
implementation does not recognize a critical extension in the
crlExtensions
field, it shall assume that identified certificates have been revoked and
are no longer valid. However in the latter case, since the list may not
be complete, certificates that have not been identified as being revoked
cannot be assumed to be valid. In this case local policy shall dictate
the action to be taken. In any case local policy may dictate actions in
addition to and/or stronger than those stated in this
Specification.

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 14 Jul 2003 10:33:38 -0400

I agree Russ - the text I quoted said "assume that identified certificates
are revoked" and without understanding and processing the certificateIssuer
extension one would not know what the "identified" certificates were because
you need the combination of issuer name and serial number. The text for that
extension says it can't be ignored, but I wonder if some additional text
should also be put in both places to make that clearer. What do you & others
think? 
 
Sharon

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Sunday, July 13, 2003 10:31 AM
To: Sharon Boeyen
Cc: [email-masked]
Subject: RE: What is mean by recognizing critical extensions ?

Sharon:

The Certificate Issuer CRL Entry Extension seems to be an exception, which
is the reason that I thought it had to be a critical extension.  If
certificate using software were to use the CRL issuer distinguished name and
the serial number associated with such an entry, then the software would
consider the wrong certificate to be revoked.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Jul 2003 10:50:24 -0400

That is always the problem with quoting a few paragraphs from a
document.  But, in this case, the implementors could use an extra
warning.  Mishandling this extension would be very bad!

Russ

At 10:33 AM 7/14/2003 -0400, Sharon Boeyen wrote:

I
agree Russ - the text I quoted said "assume that identified
certificates are revoked" and without understanding and processing
the certificateIssuer extension one would not know what the
"identified" certificates were because you need the combination
of issuer name and serial number. The text for that extension says it
can't be ignored, but I wonder if some additional text should also be put
in both places to make that clearer. What do you & others
think?

Sharon

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

From: Russ Housley
[mailto:[email-masked]]

To: Sharon Boeyen

Cc: [email-masked]

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

Sharon:

Russ

While on this topic of
critical extensions and rejections - I want to be sure everyone realizes
that  the handling is different for CRLs. If the certificate of
interest is listed as revoked on a CRL it is as a minimum considered
revoked regardless of the presence of unrecognized critical extensions.
Here is the relevant text from clause 7.3 of X.509:

NOTE 4 - When an

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 14 Jul 2003 11:14:53 -0400

I've been looking at defect reports recently anyway, so I'll draft one to
add warning for this as well and submit it to Hoyt.
 
Sharon

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, July 14, 2003 10:50 AM
To: Sharon Boeyen; Hoyt Kesterson (E-mail)
Cc: [email-masked]
Subject: RE: What is mean by recognizing critical extensions ?

That is always the problem with quoting a few paragraphs from a document.
But, in this case, the implementors could use an extra warning.  Mishandling
this extension would be very bad!

Russ

 
Sharon

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

From: Russ Housley [ mailto:[email-masked]
<mailto:[email-masked]> ]

To: Sharon Boeyen

Cc: [email-masked]

Sharon:

Russ