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:chokhani@xxxxxxxxxxxx]
Sent: den 23 juni 2006 02:48
To: Stefan Santesson;
ietf-pkix@xxxxxxx
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:stefans@xxxxxxxxxxxxx]
Sent: Thursday, June 22, 2006 8:39
PM
To: Santosh Chokhani;
ietf-pkix@xxxxxxx
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:
owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 22:59
To: ietf-pkix@xxxxxxx
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:
owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48
PM
To: Sharon Boeyen; 'Stefan
Santesson'; ietf-pkix@xxxxxxx
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: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On
Behalf Of Sharon Boeyen
Sent: Thursday, June 22, 2006 1:57
PM
To: 'Stefan Santesson';
ietf-pkix@xxxxxxx
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.
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006
5:23 PM
To: ietf-pkix@xxxxxxx
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:
owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: ietf-pkix@xxxxxxx
Subject: last call for 3280bis
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.