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

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Thu, 22 Jun 2006 14:48:05 -0400

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 order 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: Thu, 22 Jun 2006 23:03:58 +0100

I think my initial statement was a bit misinterpreted.

I suggest no changes to RFC 3280 path processing. And of course,
skipping mandatory checks would make the path processing non-conformant.

However. I have noticed that it is not clear to some people weather a
conformant implementation are forced to always do conformant path
processing, or if a conformant implementation can allow administrators
to turn of certain checking.

What I say is mainly two things;

1)       Misconfigured PKIs may sometimes force relying parties to do
non conformant path processing or fail altogether.

2)       A conformant implementation should be allowed to support also
non-conformant processing as long as this is not the default behavior.

I think this is already allowed, but some implementers may not read it
that way and therefore I'm asking if we should add a clarification like
pki4ipsec did.

Stefan Santesson

Senior Program Manager

________________________________

From: Guida, Richard [JJCUS] [mailto:[email-masked]] 
Sent: den 22 juni 2006 20:48
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