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:* 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 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:* 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
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