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

From: Sharon Boeyen <[email-masked]>
Date: Fri, 11 Jul 2003 08:43:16 -0400

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:<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />

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: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 11 Jul 2003 16:31:23 +0200 (CEST)

Contrary to others, I don't believe the problem lies in the word
"recognises" itself.  It's more the whole sentence that seems to be
confusing (and I agree with those who think so).

To me, the quoted language from X.509 certainly seems to say "if you
recognise this extension, you must process it or invalidate the path,
period", while the quote text from the other document seems to say "if
you recognise this extension and can process it, you must process it".

In pseudo-C terms, I get it like this:

X.509:	if (recognise(extension)) {
		if (can_process(extension))
			process(extension);	
		else
			invalidate(path);
	} else if (critical(extension)) {
		invalidate(path);
	}

other:	if (recognise(extension) && can_process(extension)) {
		process(extension);
	} else if (critical(extension)) {
		invalidate(path);
	}

Makes sense?

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

In message <[email-masked]> on Fri, 11 Jul 2003 08:43:16 -0400, Sharon Boeyen <[email-masked]> said:

sharon.boeyen> I have no objection to eliminating "recognizes" from the text if it is felt
sharon.boeyen> necessary, but I also want to point out the text that is only a little bit
sharon.boeyen> further down in clause 8
sharon.boeyen> of X.509:
sharon.boeyen>  
sharon.boeyen> A validation engine has two possible actions to take with respect to an
sharon.boeyen> extension:<?xml:namespace prefix = o ns =
sharon.boeyen> "urn:schemas-microsoft-com:office:office" />
sharon.boeyen> 
sharon.boeyen> i)      it can ignore the extension and accept the certificate (all other
sharon.boeyen> things being equal);
sharon.boeyen> 
sharon.boeyen> ii)     it can process the extension and accept or reject the certificate
sharon.boeyen> depending on the content of the extension and the conditions under which
sharon.boeyen> processing is occuring (e.g. the current values of the path processing
sharon.boeyen> variables).
sharon.boeyen> 
sharon.boeyen> Some extensions can only be marked critical. In these cases a validation
sharon.boeyen> engine that understands the extension, processes it and acceptance/rejection
sharon.boeyen> of the certificate is dependent (at least in part) on the content of the
sharon.boeyen> extension. A validation engine that does not understand the extension
sharon.boeyen> rejects the certificate.
sharon.boeyen> 
sharon.boeyen> Some extensions can only be marked non-critical. In these cases a validation
sharon.boeyen> engine that understands the extension processes it and acceptance/rejection
sharon.boeyen> of the certificate is dependent (at least in part) on the content of the
sharon.boeyen> extension. A validation engine that does not understand the extension
sharon.boeyen> accepts the certificate (unless factors other than this extension cause it
sharon.boeyen> to be rejected).
sharon.boeyen> 
sharon.boeyen> Some extensions can be marked critical or non-critical. In these cases a
sharon.boeyen> validation engine that understands the extension processes it and
sharon.boeyen> acceptance/rejection of the certificate is dependent (at least in part) on
sharon.boeyen> the content of the extension, regardless of the criticality flag. A
sharon.boeyen> validation engine that does not understand the extension accepts the
sharon.boeyen> certificate if the extension is marked non-critical (unless factors other
sharon.boeyen> than this extension cause it to be rejected) and rejects the certificate if
sharon.boeyen> the extension is marked critical.
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen> While I suppose it could be argued that "understands" is not much better
sharon.boeyen> than "recognizes", I think the final paragraph is clearer about what a
sharon.boeyen> validation engine is required to do. 
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen> I think that when we changed all this text the last time, there were some
sharon.boeyen> voices that opposed eliminating "recognizes" from the text because that is
sharon.boeyen> the only term that was used in the 3rd edition. Perhaps there is no longer
sharon.boeyen> support for that position. Note that these changes were a result of defect
sharon.boeyen> report 244 against the 3rd edition text (resolution published in TC 2 for
sharon.boeyen> 3rd edition and integrated into 4th edition text).
sharon.boeyen> 
sharon.boeyen> Sharon
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen> -----Original Message-----
sharon.boeyen> From: Hoyt L. Kesterson II [mailto:[email-masked]]
sharon.boeyen> Sent: Thursday, July 10, 2003 8:47 PM
sharon.boeyen> To: [email-masked]
sharon.boeyen> Subject: Re: What is mean by recognizing critical extensions ?
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> valid point. i don't see much value to considering "recognizes" as meaning
sharon.boeyen> i've heard about the extension but have no ability to process it. this
sharon.boeyen> possibly should be addressed in two places
sharon.boeyen> 
sharon.boeyen>  1) ietf agreed terminology for stating the capabilities of an
sharon.boeyen> implementation
sharon.boeyen> 
sharon.boeyen>   2) a clean-up of both ietf and iso/itu standard terminology. somewhere i
sharon.boeyen> had some additional text that i considered that stated that the
sharon.boeyen> implementation processed the extension according to the rules specified in
sharon.boeyen> the standard (old osi conformance lingo)
sharon.boeyen> 
sharon.boeyen>       hoyt
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> Hoyt,
sharon.boeyen> 
sharon.boeyen> I think the "dispute" is over the term "recognizes".  Hypothetically, an
sharon.boeyen> implementation may not have the code to "process" a given extension, but
sharon.boeyen> might claim to have the code to "recognize" the extension (and thereby hope
sharon.boeyen> to satisfy some extended compliance criteria, if erroneously).
sharon.boeyen> 
sharon.boeyen> If one defines "recognizes" IFF "possesses the code to fully process", the
sharon.boeyen> dispute disappears.  But then, the conjunction "recognizes AND is able to
sharon.boeyen> process" (highlighted below) is indeed redundant, and plausibly misleading.
sharon.boeyen> 
sharon.boeyen> Cheers!  ____tony____
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> I believe that this sentence
sharon.boeyen> 
sharon.boeyen>  When a certificate-using implementation recognizes and is able to process
sharon.boeyen> an extension, then the certificate-using implementation shall process the
sharon.boeyen> extension regardless of the value of the criticality flag.
sharon.boeyen> 
sharon.boeyen> means that if an implementation has the code to process an extension, it
sharon.boeyen> must do so. if it doesn't have the code, then it will not process an
sharon.boeyen> extension because it cannot process it. if, in that case, that extension is
sharon.boeyen> flagged critical, then it cannot use the certificate.
sharon.boeyen> 
sharon.boeyen> if anyone believe that the text says that an extension doesn't have to be
sharon.boeyen> processed even though there is an ability to process the extension, i.e. a
sharon.boeyen> belief that not being critical means that one can choose to process it or
sharon.boeyen> not, then i will recommend additional text for the standard to further
sharon.boeyen> clarify the meaning for i can see no useful result from such potential
sharon.boeyen> arbitrariness.
sharon.boeyen> 
sharon.boeyen>    hoyt
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> Tony Bartoletti 925-422-3881 <[email-masked]>
sharon.boeyen> Information Operations and Assurance Center
sharon.boeyen> Lawrence Livermore National Laboratory
sharon.boeyen> Livermore, CA 94551-9900
sharon.boeyen> 
sharon.boeyen>

---

From: "Wahaj" <[email-masked]>
Date: Fri, 11 Jul 2003 20:35:51 +0500

Re: What is mean by recognizing critical extensions ?After all the discussion, what I have understood is:

1) If extension is marked as Critical, application MUST process it. If an application can't process it, REJECT the chain altogether
2) If extension is NOT marked as Critical, you may not process it

Process mean: To read the extension, its values and check it according to some defined rules.

Don't you think option 1 is a bit harsh. Lets consider an example, if I have certificate from my CA, having SubjectAltName marked as critical ( why marked as critical ? cuz I use an application from the same CA, which process SubjectAltName). If lets say I want to use the same certificate in a scenario e.g. Buying books from XYZ.com who have implemented SSL with Client Side Authentication. If XYZ.com don't process SubjectAltName and according to RFC 3280 they reject my certificate, I can't use their service !!. This ask for another cert may be from another CA. 

Best Regards,
Wahaj

  ----- Original Message ----- 
  From: Sharon Boeyen 
  To: 'Hoyt L. Kesterson II' ; [email-masked] 
  Sent: Friday, July 11, 2003 5:43 PM
  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____

         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

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 11 Jul 2003 08:43:38 -0700 (PDT)

Hi Richard,
    Not quite. I think what most folks are saying is that you
only say you recognize an extension if you CAN process it. So, in
pseudo-C/STL code, it works something like this:

int
recognize(extension)
{
    return((know(extension.oid) && canProcess(extension.oid));
}

dealwithcert(cert)
{
    for(extension=cert.extensions.first(); extension; extension++)
    {
        if(recognize(extension))
            process(extention);
        else if(critical(extension))
            reject(cert);
    }
    return(0);
}

Wow, this pseudo-C is fun!

:-)
Ambarish
> Levitte Programming | http://www.lp.se/           | S-168 36 Bromma T:
> +46-708-26 53 44 |                             | SWEDEN
> In message
> <[email-masked]> on Fri,
> 11 Jul 2003 08:43:16 -0400, Sharon Boeyen <[email-masked]>
> said:
>
> sharon.boeyen> I have no objection to eliminating "recognizes" from the
> text if it is felt sharon.boeyen> necessary, but I also want to point
> out the text that is only a little bit sharon.boeyen> further down in
> clause 8
> sharon.boeyen> of X.509:
> sharon.boeyen>
> sharon.boeyen> A validation engine has two possible actions to take with
> respect to an sharon.boeyen> extension:<?xml:namespace prefix = o ns =
> sharon.boeyen> i)      it can ignore the extension and accept the
> certificate (all other sharon.boeyen> things being equal);
> sharon.boeyen>
> sharon.boeyen> ii)     it can process the extension and accept or reject
> the certificate sharon.boeyen> depending on the content of the extension
> and the conditions under which sharon.boeyen> processing is occuring
> (e.g. the current values of the path processing sharon.boeyen>
> variables).
> sharon.boeyen>
> sharon.boeyen> Some extensions can only be marked critical. In these
> cases a validation sharon.boeyen> engine that understands the extension,
> processes it and acceptance/rejection sharon.boeyen> of the certificate
> is dependent (at least in part) on the content of the sharon.boeyen>
> sharon.boeyen> Some extensions can only be marked non-critical. In these
> cases a validation sharon.boeyen> engine that understands the extension
> processes it and acceptance/rejection sharon.boeyen> of the certificate
> is dependent (at least in part) on the content of the sharon.boeyen>
> sharon.boeyen> accepts the certificate (unless factors other than this
> extension cause it sharon.boeyen> to be rejected).
> sharon.boeyen>
> sharon.boeyen> Some extensions can be marked critical or non-critical.
> In these cases a sharon.boeyen> validation engine that understands the
> extension processes it and sharon.boeyen> acceptance/rejection of the
> certificate is dependent (at least in part) on sharon.boeyen> the
> content of the extension, regardless of the criticality flag. A
> sharon.boeyen> validation engine that does not understand the extension
> accepts the sharon.boeyen> certificate if the extension is marked
> non-critical (unless factors other sharon.boeyen> than this extension
> cause it to be rejected) and rejects the certificate if sharon.boeyen>
> sharon.boeyen> While I suppose it could be argued that "understands" is
> not much better sharon.boeyen> than "recognizes", I think the final
> paragraph is clearer about what a sharon.boeyen> validation engine is
> required to do.
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> I think that when we changed all this text the last time,
> there were some sharon.boeyen> voices that opposed eliminating
> "recognizes" from the text because that is sharon.boeyen> the only term
> that was used in the 3rd edition. Perhaps there is no longer
> sharon.boeyen> support for that position. Note that these changes were a
> result of defect sharon.boeyen> report 244 against the 3rd edition text
> (resolution published in TC 2 for sharon.boeyen> 3rd edition and
> integrated into 4th edition text).
> sharon.boeyen>
> sharon.boeyen> Sharon
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> From: Hoyt L. Kesterson II
> [mailto:[email-masked]] sharon.boeyen> Sent: Thursday, July
> 10, 2003 8:47 PM
> sharon.boeyen> Subject: Re: What is mean by recognizing critical
> extensions ? sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> valid point. i don't see much value to considering
> "recognizes" as meaning sharon.boeyen> i've heard about the extension
> but have no ability to process it. this sharon.boeyen> possibly should
> be addressed in two places
> sharon.boeyen>
> sharon.boeyen>  1) ietf agreed terminology for stating the capabilities
> of an sharon.boeyen> implementation
> sharon.boeyen>
> sharon.boeyen>   2) a clean-up of both ietf and iso/itu standard
> terminology. somewhere i sharon.boeyen> had some additional text that i
> considered that stated that the sharon.boeyen> implementation processed
> the extension according to the rules specified in sharon.boeyen> the
> standard (old osi conformance lingo)
> sharon.boeyen>
> sharon.boeyen>       hoyt
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> Hoyt,
> sharon.boeyen>
> sharon.boeyen> I think the "dispute" is over the term "recognizes".
> Hypothetically, an sharon.boeyen> implementation may not have the code
> to "process" a given extension, but sharon.boeyen> might claim to have
> the code to "recognize" the extension (and thereby hope sharon.boeyen>
> sharon.boeyen> If one defines "recognizes" IFF "possesses the code to
> fully process", the sharon.boeyen> dispute disappears.  But then, the
> conjunction "recognizes AND is able to sharon.boeyen> process"
> (highlighted below) is indeed redundant, and plausibly misleading.
> sharon.boeyen>
> sharon.boeyen>  When a certificate-using implementation recognizes and
> is able to process sharon.boeyen> an extension, then the
> certificate-using implementation shall process the sharon.boeyen>
> sharon.boeyen> means that if an implementation has the code to process
> an extension, it sharon.boeyen> must do so. if it doesn't have the code,
> then it will not process an sharon.boeyen> extension because it cannot
> process it. if, in that case, that extension is sharon.boeyen> flagged
> critical, then it cannot use the certificate. sharon.boeyen>
> sharon.boeyen> if anyone believe that the text says that an extension
> doesn't have to be sharon.boeyen> processed even though there is an
> ability to process the extension, i.e. a sharon.boeyen> belief that not
> being critical means that one can choose to process it or sharon.boeyen>
> sharon.boeyen> clarify the meaning for i can see no useful result from
> such potential sharon.boeyen> arbitrariness.
> sharon.boeyen>
> sharon.boeyen>    hoyt
> sharon.boeyen>
> sharon.boeyen>

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Fri, 11 Jul 2003 12:44:29 -0700

wahaj

if by "may not process it" you mean "you don't
have to implement support" then you are correct. if you mean
"arbitrarily decide not to process it" even though the
implementation supports it, then you are not in alignment with the
standard. - please reference text that i quoted from the
standard.

item 1 is not harsh. if one assumes that a ca has decided that
the information in the extension shall be considered to determine if
the certificate is appropriate, then one should be able to handle the
extension - by handle i mean process according to the procedures
defined in the standard and, if appropriate, constrained by a
certificate use profile such as pkix.

i suggest you look at the additional paragraphs i mentioned in my
email (and may be present in sharon's email). it points out that
injudicious flagging of extensions as critical may limit users.
however, if the ca has decided that the processing of an extension is
necessary for correct operation, i  can't see why the ca would
want to widen the number of potential users to include those who will
not use the certificate as the ca intended.

hoyt

After all
the discussion, what I have understood is:

1) If
extension is marked as Critical, application MUST process it. If
an application can't process it, REJECT the chain
altogether

2) If
extension is NOT marked as Critical, you may not process
it

Process
mean: To read the extension, its values and check it according to some
defined rules.

Don't you
think option 1 is a bit harsh. Lets consider an example, if I have
certificate from my CA, having SubjectAltName marked as critical ( why
marked as critical ? cuz I use an application from the same CA, which
process SubjectAltName). If lets say I want to use the same
certificate in a scenario e.g. Buying books from XYZ.com who have
implemented SSL with Client Side Authentication. If XYZ.com don't
process SubjectAltName and according to RFC 3280 they reject my
certificate, I can't use their service !!. This ask for another cert
may be from another CA.

Best
Regards,

Wahaj

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

From: Sharon Boeyen

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

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____

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

Content-Type: application/x-pkcs7-signature;

name="smime.p7s"

Content-Disposition: attachment;

filename="smime.p7s"

Attachment converted: Macintosh HD:smime 2.p7s (????/----)
(00057A66)