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

From: Brad Hards <[email-masked]>
Date: Fri, 23 Jun 2006 22:02:43 +1000

On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote:
> There should not be any escape clause in 3280bis for any non-conformant
> behavior. 3280bis is a profile of X.509 - it is not a narrative to describe
> various types of non-conformant behavior, regardless of what it is.
Perhaps there might be a role for an Informational RFC that explains the 
various issues that are a source of concern. Ideally it would provide some 
guidance on how to deal with the non-conformant behaviour. At the very least 
it could explain the consequences of particular courses of action.

Brad

---

From: Sharon Boeyen <[email-masked]>
Date: Fri, 23 Jun 2006 07:12:13 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Friday, June 23, 2006 5:28 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: last call for 3280bis - escape clause

Santosh,

Yes, you are correct that the path will validate without any error in your
example. 

It will also have an empty set of valid policies. So accepting the EE
certificate policies as valid (using that path) do require some kind of
non-conformant policy checking.

I agree on your conclusion. However I have experienced implementers not
feeling sure about this principle. Especially when it comes to configuration
options enabled by an administrative UI and not just some mode switch in the
OS.

The escape clause in pki4ipsic was driven by this uncertainty.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

  _____  

From: Santosh Chokhani [mailto:[email-masked]] 
Sent: den 23 juni 2006 02:48
To: Stefan Santesson; [email-masked]
Subject: RE: last call for 3280bis - escape clause

Stefan,

On disagree with you on 2.  You seem to be asking for 2 and then saying that
it is not valid.

A path validation profile (assuming we agree to ignore "require explicit
policy") with setting acceptable policy set to anyPolicy is valid X.509 and
3280 configuration.  In that case, there will not be a policy failure and
relying party can always make additional checks.  I encourage you to look at
Section J.3 in Annex J of X.509.  If you see any errors in Annex J, please
let me know.

As to Standard compliant implementation putting itself in non-compliant
mode, that is always acceptable.  In that mode it will NOT be standard
compliant; that is all.

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, June 22, 2006 8:39 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: last call for 3280bis - escape clause

Santosh,

There are 2 distinct reasons why your approach is not a generic solution to
the problem.

1)       The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with EKU
settings in existing certificates that does not satisfy new applications and
usages.

2)       If you need to test for a policy in the end certificate, that
policy will not be valid unless supported by the path, regardless if policy
constraints was set or not.

In the perfect world, compliant path processing will always do the job. In
the real world, you may need to tweak the rules to make a new application
fit into an existing infrastructure-

The question is still: Can a standards compliant implementation allow
configuration of non conformant modifications to the validation process, or
does that make the implementation as a whole non-conformant.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 22:59
To: [email-masked]
Subject: RE: last call for 3280bis - escape clause

Stefan,

I agree with sentiments voiced by Steve, Rich, and Sharon.

I have a simple solution to your concern from the relying party viewpoint.
This observation is made with a long-held view of mine (and no one had
provided a convincing logical or business argument) that the require
explicit policy setting is a useless field.  A relying party can always set
acceptable policies to none.  In that scenario, (require explicit policy)
flag not withstanding, path validation will succeed.  Now, the user can
examine the end certificate policy.

You and I have had this discussion in another context.  The basic premise is
that if some field in the last certificate only is of interest and the
"state" in the path validation process does not impact it, that need not be
path of path validation engine.

Thus, you can judiciously use the 3280 Engine and obtain the result you
seek.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48 PM
To: Sharon Boeyen; 'Stefan Santesson'; [email-masked]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

Stefan - perhaps I am missing something, but there is nothing that stops a
relying party from writing software that would perform processing extensions
only on CA certs as you propose.  As Sharon properly notes, that would not
be RFC3280 compliant - but a relying party can choose to be non-compliant if
it wishes.  And such non-compliance only puts the relying party at risk, not
others - so that is a "good thing" relatively speaking.  But in the final
analysis, seems to me that Sharon is absolutely correct (assuming she and I
are interpreting your proposal properly) - unless X.509 is redefined, this
would remain a circumstance of non-compliance.  And so it should be treated
as such.  Very best regards -- Rich

Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  732 524 3785 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Sharon Boeyen
Sent: Thursday, June 22, 2006 1:57 PM
To: 'Stefan Santesson'; [email-masked]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

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 orde!
 r t
 o 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: "Stefan Santesson" <[email-masked]>
Date: Sat, 24 Jun 2006 13:09:53 +0100

Personally I feel positive about such initiative even though I fear the
volume of debates it might cause. I would like to hear the rest of the
WG on this.

I do acknowledge that we are facing practical problems out there that
the standard can't solve today.

Stefan Santesson
Senior Program Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Brad Hards
Sent: den 23 juni 2006 14:03
To: Sharon Boeyen
Cc: [email-masked]
Subject: Re: last call for 3280bis - escape clause

various issues that are a source of concern. Ideally it would provide
some 
guidance on how to deal with the non-conformant behaviour. At the very
least 
it could explain the consequences of particular courses of action.

Brad

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 24 Jun 2006 13:04:50 +0100

Sharon,

I fully agree. We should not describe any non conformant behavior. I
hope you haven't interpreted my question in that manner.

Stefan Santesson

Senior Program Manager

________________________________

From: Sharon Boeyen [mailto:[email-masked]] 
Sent: den 23 juni 2006 13:12
To: Stefan Santesson; Santosh Chokhani; [email-masked]
Subject: RE: last call for 3280bis - escape clause

There should not be any escape clause in 3280bis for any non-conformant
behavior. 3280bis is a profile of X.509 - it is not a narrative to
describe various types of non-conformant behavior, regardless of what it
is. 

-----Original Message-----
On Behalf Of Stefan Santesson

	Santosh,

	Yes, you are correct that the path will validate without any
error in your example. 

	It will also have an empty set of valid policies. So accepting
the EE certificate policies as valid (using that path) do require some
kind of non-conformant policy checking.

	I agree on your conclusion. However I have experienced
implementers not feeling sure about this principle. Especially when it
comes to configuration options enabled by an administrative UI and not
just some mode switch in the OS.

	 

	Stefan Santesson

	Senior Program Manager

________________________________

	Stefan,

	On disagree with you on 2.  You seem to be asking for 2 and then
saying that it is not valid.

	A path validation profile (assuming we agree to ignore "require
explicit policy") with setting acceptable policy set to anyPolicy is
valid X.509 and 3280 configuration.  In that case, there will not be a
policy failure and relying party can always make additional checks.  I
encourage you to look at Section J.3 in Annex J of X.509.  If you see
any errors in Annex J, please let me know.

	As to Standard compliant implementation putting itself in
non-compliant mode, that is always acceptable.  In that mode it will NOT
be standard compliant; that is all.

________________________________

	Santosh,

	There are 2 distinct reasons why your approach is not a generic
solution to the problem.

	1)       The problem is generic and does not only apply to
policy processing. The pki4ipsec issue was e.g. motivated from problems
with EKU settings in existing certificates that does not satisfy new
applications and usages.

	2)       If you need to test for a policy in the end
certificate, that policy will not be valid unless supported by the path,
regardless if policy constraints was set or not.

	In the perfect world, compliant path processing will always do
the job. In the real world, you may need to tweak the rules to make a
new application fit into an existing infrastructure-

	The question is still: Can a standards compliant implementation
allow configuration of non conformant modifications to the validation
process, or does that make the implementation as a whole non-conformant.

	Stefan Santesson

	Senior Program Manager

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Santosh Chokhani
	Sent: den 22 juni 2006 22:59
	To: [email-masked]
	Subject: RE: last call for 3280bis - escape clause

	Stefan,

	I have a simple solution to your concern from the relying party
viewpoint.  This observation is made with a long-held view of mine (and
no one had provided a convincing logical or business argument) that the
require explicit policy setting is a useless field.  A relying party can
always set acceptable policies to none.  In that scenario, (require
explicit policy) flag not withstanding, path validation will succeed.
Now, the user can examine the end certificate policy.

	You and I have had this discussion in another context.  The
basic premise is that if some field in the last certificate only is of
interest and the "state" in the path validation process does not impact
it, that need not be path of path validation engine.

	Thus, you can judiciously use the 3280 Engine and obtain the
result you seek.

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Guida, Richard
[JJCUS]
	Sent: Thursday, June 22, 2006 2:48 PM
	To: Sharon Boeyen; 'Stefan Santesson'; [email-masked]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	Stefan - perhaps I am missing something, but there is nothing
that stops a relying party from writing software that would perform
processing extensions only on CA certs as you propose.  As Sharon
properly notes, that would not be RFC3280 compliant - but a relying
party can choose to be non-compliant if it wishes.  And such
non-compliance only puts the relying party at risk, not others - so that
is a "good thing" relatively speaking.  But in the final analysis, seems
to me that Sharon is absolutely correct (assuming she and I are
interpreting your proposal properly) - unless X.509 is redefined, this
would remain a circumstance of non-compliance.  And so it should be
treated as such.  Very best regards -- Rich

	Richard A. Guida 

	Johnson & Johnson 
	Room GS8217 
	410 George Street 

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]]On Behalf Of Sharon Boeyen
		Sent: Thursday, June 22, 2006 1:57 PM
		To: 'Stefan Santesson'; [email-masked]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		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.

		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 orde!
			 r t
			 o 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

________________________________

			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