Subject: Inhibit Any-Policy extension

From: "Peter Hesse" <[email-masked]>
Date: Tue, 29 Jul 2008 15:03:16 -0400

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."

X.509 says "This extension may, at the option of the certificate issuer, be
either critical or non-critical. It is recommended that it be critical,
otherwise a certificate user may not correctly interpret the stipulation of
the issuing CA."

We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit anyPolicy.
This is most likely because of the wording in 3280 (This extension MUST be
critical).  The PKI policy authority made the decision to mark this
extension non-critical following X.509.  We will work on getting the
certificate processing implementation to be more forgiving, but in the
meantime it bring up this question: Why does RFC5280 differ from X.509 on
the criticality of this extension?  There is a pretty significant difference
between a "recommendation" and a "MUST".

Thanks,

--Peter

  _____  

 Peter Hesse                       [email-masked]

 Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.

    Visit our relaunched website!  <http://geminisecurity.com/>
http://geminisecurity.com

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 29 Jul 2008 15:56:06 -0400

Peter,

5280 processing rules recommend that relying party not enforce this
criticality.  I recommend that the relying party software in your
situation be modified to not check and enforce criticality.

See paragraph 3 of Section 6.1 of 5280 and I quote below:

"While the certificate and CRL profiles specified in Sections 4 and 5

   of this document specify values for certificate and CRL fields and

   extensions that are considered to be appropriate for the Internet

   PKI, the algorithm presented in this section is not limited to

   accepting certificates and CRLs that conform to these profiles.

   Therefore, the algorithm only includes checks to verify that the

   certification path is valid according to X.509 and does not include

   checks to verify that the certificates and CRLs conform to this

   profile.  While the algorithm could be extended to include checks for

   conformance to the profiles in Sections 4 and 5, this profile

   RECOMMENDS against including such checks."

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Hesse
Sent: Tuesday, July 29, 2008 3:03 PM
To: [email-masked]
Subject: Inhibit Any-Policy extension

X.509 says "This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA."

We have found a case in which a certificate processing implementation
has rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in the meantime it bring up this question: Why does RFC5280 differ
from X.509 on the criticality of this extension?  There is a pretty
significant difference between a "recommendation" and a "MUST".

Thanks,

--Peter

________________________________

    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/>

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 30 Jul 2008 10:49:52 +0400

We often come across such situations not only because of differences in
standards but also because CAs tend to do their own thing sometime with
regards to setting the criticality flag or not.  

I would go a step further, i.e. the safe conclusion for sake of
interoperability from a practical point of view is the following:

-          It should not be the job of RP applications to enforce
"criticality"

-          Instead RP applications should simply process the extensions they
recognise, if there is an extension which is not recognised and it is marked
critical then the RP application should not accept that certificate.  

Regards,

LK

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: 29 July 2008 23:56
To: Peter Hesse; [email-masked]
Subject: RE: Inhibit Any-Policy extension

Peter,

5280 processing rules recommend that relying party not enforce this
criticality.  I recommend that the relying party software in your situation
be modified to not check and enforce criticality.

 

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Hesse
Sent: Tuesday, July 29, 2008 3:03 PM
To: [email-masked]
Subject: Inhibit Any-Policy extension

Thanks,

--Peter

  _____

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jul 2008 10:56:11 +0200

rfc 3161 requires in 2.3

   The
   corresponding certificate MUST contain only one instance of the
   extended key usage field extension as defined in [RFC2459] Section
   4.2.1.13 with KeyPurposeID having value:

   id-kp-timeStamping.  This extension MUST be critical.

Some TSA do not set this, and there exist relying party software that
rejects a certficat with a non critical extended keyusage.

Peter

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 Jul 2008 05:44:44 -0400

I my opinion, RFC 5280 got it right.  If a CA includes this
extension it MUST be critical.  This setting will ensure that all
relying parties honor it.  This is not a setting that is appropriate
for some relying parties to honor and others not.

Russ

At 03:03 PM 7/29/2008, Peter Hesse wrote:

Regarding the Inhibit anyPolicy
extension (id-ce 54), RFC 5280 says “Conforming CAs MUST mark this
extension as critical.”

X.509 says “This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA.”

We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the
decision to mark this extension non-critical following X.509.  We
will work on getting the certificate processing implementation to be more
forgiving, but in the meantime it bring up this question: Why does
RFC5280 differ from X.509 on the criticality of this extension?
There is a pretty significant difference between a “recommendation” and a
“MUST”.

Thanks,

--Peter

Peter
Hesse
[email-masked]

Phone: 703-378-5808 x105      Gemini
Security Solutions, Inc.

Visit our relaunched website!
http://geminisecurity.com

"A good programmer is someone who always looks both ways
before

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jul 2008 13:35:33 +0200

Russ Housley wrote:
> I my opinion, RFC 5280 got it right. If a CA includes this extension 
> it MUST be critical. This setting will ensure that all relying parties 
> honor it. This is not a setting that is appropriate for some relying 
> parties to honor and others not.
I agree.

But is it correct for a relying party that recognizes the extension to 
look at the criticality at all:

   A
   certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be
   processed if it is recognized. 

>> “Conforming CAs MUST mark this extension as critical.”
>>
>> X.509 says “This extension may, at the option of the certificate 
>> issuer, be either critical or non-critical. It is recommended that it 
>> be critical, otherwise a certificate user may not correctly interpret 
>> the stipulation of the issuing CA.”
>>
>> decision to mark this extension non-critical following X.509. We will 
>> work on getting the certificate processing implementation to be more 
>> RFC5280 differ from X.509 on the criticality of this extension? There 
>> is a pretty significant difference between a “recommendation” and a 
>> “MUST”.
>>
>> Thanks,
>>
>> --Peter
>>
>> ------------------------------------------------------------------------
>> /"A good programmer is someone who always looks both ways before
>> /

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 30 Jul 2008 11:14:41 -0400

Peter,

As was previously noted, the relying party should not be rejecting the
certificate simply because the extension is marked non-critical.

As to your question of why does RFC 5280 differ from X.509, it is
because one is the base standard, which defines the extension, and the
other is a profile.  The purpose of RFC 5280 is to profile X.509, not
simply reformat it as an RFC.

X.509 does not mandate that any public key certificate extension be
marked critical.  Each extension is either marked as always
non-critical or optionally critical. (X.509 does mandate that some CRL
extensions always be marked critical.)  I believe that it was fully
expected by the authors of X.509 that profiles would mandate that some
of the extensions be marked critical.

Dave

Peter Hesse wrote:

Regarding the Inhibit anyPolicy extension (id-ce
54), RFC 5280
says “Conforming CAs MUST mark this extension as critical.”

X.509 says “This extension may, at the option of
the
certificate issuer, be either critical or non-critical. It is
recommended that
it be critical, otherwise a certificate user may not correctly
interpret the
stipulation of the issuing CA.”

We have found a case in which a certificate
processing
implementation has rejected a certificate because it has a non-critical
inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the
decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in
the meantime it bring up this question: Why does RFC5280 differ from
X.509 on the
criticality of this extension?  There is a pretty significant
difference
between a “recommendation” and a “MUST”.

Thanks,

--Peter

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 30 Jul 2008 16:13:37 -0400

Russ,

Making inhibit anyPolicy non-critical is desirable, RFC 5280
notwithstanding.

Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.  Many clients do not support it.  Making this
extension non-critical should let you have your cake and eat it to.
Below is the rationale.

The clients that recognize the extension must enforce it regardless of
criticality.  These clients will securely process the extension.

The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction
with it and hence not processing the extension will be a wash, skipCerts
> 0 notwithstanding, which most PKIs do not do.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Wednesday, July 30, 2008 5:45 AM
To: Peter Hesse; [email-masked]
Subject: Re: Inhibit Any-Policy extension

I my opinion, RFC 5280 got it right.  If a CA includes this extension it
MUST be critical.  This setting will ensure that all relying parties
honor it.  This is not a setting that is appropriate for some relying
parties to honor and others not.

Russ

 

Thanks,
 
--Peter

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 31 Jul 2008 09:54:08 -0400

Russ,

I do not recall the list having a discussion on this.

Besides, I am not saying revise 5280.

I am stating what is prudent and am providing the rationale for it.

Technical accuracy is not a matter of consensus, no matter how big the
group is or who is in it.  It is a matter of sound logic.

From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, July 31, 2008 9:50 AM
To: Santosh Chokhani; Peter Hesse; [email-masked]
Subject: RE: Inhibit Any-Policy extension

Santosh:

I disagree.  Given that RFC 5280 (and RFC 3280 before that) had
consensus , I see no reason to revisit the discussion.

Russ

At 04:13 PM 7/30/2008, Santosh Chokhani wrote:

Russ,

 

From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Russ Housley
Sent: Wednesday, July 30, 2008 5:45 AM
To: Peter Hesse; [email-masked]
Subject: Re: Inhibit Any-Policy extension

Russ

 

Thanks,
 
--Peter

---

From: Russ Housley <[email-masked]>
Date: Thu, 31 Jul 2008 09:50:01 -0400

Santosh:

Russ

Russ,

Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.  Many clients do not support it.  Making
this extension non-critical should let you have your cake and eat it
to.  Below is the rationale.

The clients that recognize the extension must enforce it regardless of
criticality.  These clients will securely process the
extension.

> 0 notwithstanding, which most PKIs do not do.

From: [email-masked]
[
mailto:[email-masked]] On Behalf Of Russ
Housley

Russ

Thanks,

--Peter

Peter
Hesse