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

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 23 Jun 2006 04:44:17 -0700

Stefan,

We seem to be converging.

The way the relying party should see it and that is why I find the path
processing to be compliant with X.509 and 3280 is as follows:

The path is good for no policies.  The relying party accepts a path that
is not good for any policy and makes an additional check (which the
standards permit) to see if the end certificate has the desired policy.

I hope this clarifies the standard compliance.

________________________________

From: Stefan Santesson [mailto:[email-masked]] 
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