Subject: RE: last call for 3280bis - escape clause

From: Sharon Boeyen <[email-masked]>
Date: Thu, 22 Jun 2006 13:56:51 -0400

Stefan, if I understand your comment correctly I strongly believe such an
escape clause cannot possibly be added because this would render 3280bis
non-compliant with X.509. 
 
My understanding of your comment is that the escape clause would enable a
path validation engine to process the certificate policy OIDs found in CA
certificates but ignore those found in EE certificates. Is that a correct
understanding? 
 
If it is a correct understanding, then any such implementation is
non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate
certain optional elements or exclude optional elements but cannot reverse
the mandatory processing from X.509.
 
Apologies if I've misunderstood your question.
 
Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: [email-masked]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

As a last call comment on RFC 3280bis I would like to raise the question
whether RFC 3280bis should include an escape clause clearly allowing relying
parties to select what validation logic they deploy on certificate
validation.

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and
their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the
list of EE certificate policies that are valid for a path. Yet many
deployments have included pure CA certificate policies in CA certificates,
policies that are not included in any EE certificates and as such, policy
processing is not possible in such PKIs.

Application wanting to use certificate policies in such PKI are simply
forced to either fail or selectively neglect certain path processing rules.
For a relying party such modification could be reasonable if the security
implications has been well though through.

However it is not clear if an implementation allowing such local
configuration could be regarded as standard compliant.

There are more examples where deploying applications in misconfigured PKIs
would need similar measures to work.

The pki4ipsec WG recently came to this conclusion in their PKI profile and
this lead to an intense debate which included core participants from the
PKIX WG.

The result was that the pki4ipsec profile included an escape clause as
follows:

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in order to permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

I'm basically asking if RFC 3280bis path validation needs a similar escape
clause or corresponding clarification that clearly allows local
configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of
standards compliant applications as long as this is not the default
functionality.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: [email-masked]
Subject: last call for 3280bis

Folks,

Based on the latest message from David Cooper, I am initiating last call on
"Internet X.509 Public Key Infrastructure, Certificate and Certificate
Revocation List (CRL) Profile" (
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>
http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

The last call will last for two weeks. In deference to the U.S. Independence
Dya holiday (which means July 3rd is a holiday for many folks), all comments
must be received by July 5th.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Jun 2006 19:31:21 +0100

I guess I'd agree with Sharon's conclusion but for slightly different
reasons. If people need such a different profile of x.509 or 3280bis
then a different RFC is required IMO - given that 3280 exists it would
be wrong for 3280bis to include such a change since you'd potentially
punish 3280 implementers for being compliant.

Stephen.

Sharon Boeyen wrote:
> Stefan, if I understand your comment correctly I strongly believe such 
> an escape clause cannot possibly be added because this would render 
> 3280bis non-compliant with X.509.
>  
> My understanding of your comment is that the escape clause would enable 
> a path validation engine to process the certificate policy OIDs found in 
> CA certificates but ignore those found in EE certificates. Is that a 
> correct understanding?
>  
> non-conformant to X.509. 3280 is a profile of X.509 and as such can 
> mandate certain optional elements or exclude optional elements but 
> cannot reverse the mandatory processing from X.509.
>  
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Stefan Santesson
>     *Sent:* Wednesday, June 21, 2006 5:23 PM
>     *To:* [email-masked]
>     *Cc:* Stephen Kent
>     *Subject:* RE: last call for 3280bis - escape clause
> 
>     As a last call comment on RFC 3280bis I would like to raise the
>     question whether RFC 3280bis should include an escape clause clearly
>     allowing relying parties to select what validation logic they deploy
>     on certificate validation.
> 
>      
> 
>     One such common misconfiguration is assignment of certificate
>     policies and their inclusion in CA certificates.
> 
>     X.509 path processing requires policies in CA certificates to
>     reflect the list of EE certificate policies that are valid for a
>     path. Yet many deployments have included pure CA certificate
>     policies in CA certificates, policies that are not included in any
>     EE certificates and as such, policy processing is not possible in
>     such PKIs.
> 
>      
> 
>     Application wanting to use certificate policies in such PKI are
>     simply forced to either fail or selectively neglect certain path
>     processing rules. For a relying party such modification could be
>     reasonable if the security implications has been well though through.
> 
>     There are more examples where deploying applications in
>     misconfigured PKIs would need similar measures to work.
> 
>      
> 
>     The pki4ipsec WG recently came to this conclusion in their PKI
>     profile and this lead to an intense debate which included core
>     participants from the PKIX WG.
> 
>      
> 
>     The result was that the pki4ipsec profile included an escape clause
>     as follows:
> 
>      
> 
>     4.1.  X.509 Certificates
> 
>      
> 
>     I'm basically asking if RFC 3280bis path validation needs a similar
>     escape clause or corresponding clarification that clearly allows
>     local configuration of the validation logic.
> 
>     At least I think it is necessary to clearly allow such configuration
>     of standards compliant applications as long as this is not the
>     default functionality.
> 
>      
> 
>      
> 
>     **Stefan Santesson**
> 
>     Senior Program Manager
> 
>     **Windows Security, Standards**
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Stephen Kent
>     *Sent:* den 16 juni 2006 22:42
>     *To:* [email-masked]
>     *Subject:* last call for 3280bis
> 
>      
> 
>     Folks,
> 
>      
> 
>     Based on the latest message from David Cooper, I am initiating last
>     call on "Internet X.509 Public Key Infrastructure, Certificate and
>     Certificate Revocation List (CRL) Profile"
>     (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)
> 
>      
> 
>     The last call will last for two weeks. In deference to the U.S.
>     Independence Dya holiday (which means July 3rd is a holiday for many
>     folks), all comments must be received by July 5th.
> 
>      
> 
>     Steve
>