Subject: Setting X.509 Policy Data in IE, IIS, Outlook

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 27 Jan 2004 11:44:38 +0100

It has been touted that policy OIDs are essntial for building PKIs.

However, I have not found any place where you can can set the
policy filtering in relying party apps like MSIE, IIS, or Outlook.

I would be interested to know when this feature will be available
and how the policy-OID-related processes are supposed to work
from an end-user perspective.

In case there are such application features available from other
vendors, I would be interested in how they have addresses this
issue.

In particular, what you do after "installing" a trust anhcor does
not seem to be an not entirely straightforward matter unless you
do a lot of assumptions. 

Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Jan 2004 09:05:53 -0500

>It has been touted that policy OIDs are essntial for building PKIs.

not true in all cases, maybe not even in most cases.  who are you citing?

>policy filtering in relying party apps like MSIE, IIS, or Outlook.

well, if you choose MS products as a good example of anything, you 
are likely to be disappointed :-)  for example, the Windows 
implementation of IPsec does not provide a compliant management 
interface for the security policy database.

...

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 27 Jan 2004 16:38:42 +0100

>>However, I have not found any place where you can set the

>interface for the security policy database.

Although "MS-bashing" seems to be "come-il-faut" these days,
it would be a bit more interesting to hear how "the good guys"
(whatever that means), handle policy settings.

Borrowing from your IPsec complaints:
A "compliant management interface for the security policy database"
for X.509 would be fun to review.  As far as I can see, the X.509
policy mechanisms are flawed to the point where it becomes technically
infeasible to specify such an interface.  But I stay interested if anybody
dares to challenge that statement with something tangible instead of
the usual PKI mumbo-jumbo, like "there are many ways to do this".

Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Jan 2004 11:19:56 -0500

>(whatever that means), handle policy settings.

"MS-bashing" is not even a hobby, as it offers no challenge. but 
holding up any MS product as a reference for how a security function 
should be performed is the epitome of silliness, and warrants comment.

>the usual PKI mumbo-jumbo, like "there are many ways to do this".

A challenge with no apparent reward to motivate a response, as usual ...

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 27 Jan 2004 20:27:27 +0100

>A challenge with no apparent reward to motivate a response, as usual ...

May I help you with some analysis?

PKI projects historically started with the CA, and this has influenced
some PKI standards as well, the RFC3280 policy support is a prime
example of that.

However, being a CA, is being an "information producer" which is
considerably easier than being an "information consumer" as only the
latter has to "interpret" and maybe "act" upon what the information
producer says.

If the designers of the policy system instead had focused on the relying
party (the "information consumer"), they had probably realized that a
relying party consists of 1) the relying party software 2) the people
depending on the relying party software.

Further analysis shows that the "people" category, except in the most
trivial scenarios, consists of  "trust administrators" and "end users". 
In the background there are also some legal folks lurking around.

If you then apply the design constraint that all these entities should
have the best possible system adapted for the entities' actual tasks
and competence, you would end-up with a very different policy scheme.

Commercial CAs know that, and therefore with few exceptions, continue
to ignore a system that was not designed with the "customer in mind".

The major difference is that policy in commercial CAs is associated
with the CA, eliminating the need for moving trust processing and
trust administration tasks into the application and user domains
respectively.  This enables the creation of shrink-wrap RP software
as well as shielding end-users from too close encounters with PKI.

This also allows trust admins to anytime, using "CA properties",
view what "they actually currently trust", without having a single
EE certificate!

Anders

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Jan 2004 09:54:10 -0500

>May I help you with some analysis?

you can try, but experience suggests otherwise :-)

>some PKI standards as well, the RFC3280 policy support is a prime

successful PKI projects start with a problem that needs to be solved.

>In the background there are also some legal folks lurking around.

warning, neologism alert! "trust administrator" is a nonsense term 
created to obfuscate technical issues.

>and competence, you would end-up with a very different policy scheme.

any time someone suggests that a system should be "optimized" for 
multiple entities who may have conflicting goals, we ought to be wary.

>to ignore a system that was not designed with the "customer in mind".

commercial CAs often optimize their profit. to the exclusion of all 
else.  whether that is achieved by doing the best job for their 
clients is hard to say, since we have an effective monopoly in the 
commercial CA business, in most respects. this is like saying that 
the software with the biggest market share is that which is best for 
its users.

>as well as shielding end-users from too close encounters with PKI.

you often use the phrase "shrink wrap RP software" but never seem to 
be able to provide a non-marketing characterization. and, the 
appearance of "trust administration" here again sets off the 
neologism alert.

>view what "they actually currently trust", without having a single

alert, alert, ...

Steve

---

From: Steve Hanna <[email-masked]>
Date: Wed, 28 Jan 2004 11:08:58 -0500

At 20:27 +0100 1/27/04, Anders Rundgren wrote:
> A "compliant management interface for the security policy
> database" for X.509 would be fun to review. As far as I can
> see, the X.509 policy mechanisms are flawed to the point where
> it becomes technically infeasible to specify such an interface.
> But I stay interested if anybody dares to challenge that statement
> with something tangible instead of the usual PKI mumbo-jumbo,
> like "there are many ways to do this".

OK, I'll take the bait. But I'll pass on Peter Gutmann's "reward".

First, let me address the implicit question
"Who needs certificate policies? Why bother?"
Some PKI users want to support multiple levels of
assurance within a single PKI. For example, many
U.S. government agencies want this. To accomplish
this, they put a certificate policy extension in
each certificate indicating under which policy or
policies it was issued.

Many PKI users (CAs and relying parties) don't need
this. They can just omit all policy-related extensions
from their certificates and forget about configuring
their relying party software with policy-related
parameters.

Now, on to the matter of describing a "compliant management
interface for the security policy database". Actually,
David Cross already did this. He explained that the
Windows Server 2003 IAS Server component allows administrators
to configure the set of allowed policy OIDs. That's
equivalent to the "user-initial-policy-set" described
in RFC 3280. Some users might also want the ability
to set the other flags specified in 3280 (like
initial-policy-mapping-inhibit), but the functionality
described by David is probably sufficient for most purposes.

See, that wasn't so hard, was it? I admit that most
users won't care about or understand these parameters.
In fact, most users don't know who their trust anchors
are or what the RSA algorithm is. But that's not a good
argument for removing trust anchors and the RSA algorithm
from standards and software. It's an argumnet for providing
good default settings and good ways for administrators
and power users to modify those defaults.

I expect this email will set off another flurry of
responses, but maybe they will be more insightful
than the barrage of content-free attacks we have
had so far. I can hope, can't I? ;-)

Thanks,

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 28 Jan 2004 20:41:43 +0100

Hi Steve,
I'm sorry if you only see this as "fact-free attacks".

I don't think we will agree on this matter, it is better
to explain why we come to different conclusions.

>"Who needs certificate policies? Why bother?"

That's a perfect start!

>U.S. government agencies want this.

Here I maintain that this whish may not have only merits.
The main merits seem to be on the CA-side.

The alternative to use different PKIs have some benefits as
well, particularly with respect to relying parties.   
To have a single trust establising mechanism, should be an
advantage.  That this mechanism is compatible with pratically
every PKI-enabled software there is, is another advantage.

>To accomplish this, they put a certificate policy extension in
>each certificate indicating under which policy orpolicies it was issued.

Agreed.

>Many PKI users (CAs and relying parties) don't need this.
>They can just omit all policy-related extensions from their
>certificates and forget about configuring their relying party
>software with policy-related parameters.

Agreed.

>described by David is probably sufficient for most purposes.

This is neither wrong nor completely right as RFC3280-
complient CAs have a myriad of options to select from like
having no policy OIDs, anyPolicy OIDs and various path-validation
input flags making it hard to go beyound the level you described
as "sufficient for most purposes".  I don't disagree that this may
indeed be "sufficient", but I don't think that it really matches the
"challenge" requirements as we are talking RFC3280 subsets.

To summarize: If your focus is hugh-but-closed PKIs as represented
by some US governments you may end-up with one answer, while
if you focus on the currently not yet up-and-running many-to-many
PKI-using communities (like B2B) where relying parties do not have
PKI experts at hand, you may end-up with another answer.

A valid question is of course is how these PKIs can ever be
interoperable.  I have no answer to that.  Gateways I guess :-)

rgds
Anders

---

From: Steve Hanna <[email-masked]>
Date: Wed, 28 Jan 2004 15:36:23 -0500

> I'm sorry if you only see this as "fact-free attacks".

I apologize for implying that the whole topic
was "content-free". That's wrong. There are
some good issues here (complexity, UI concerns,
etc.). A few of the posts have been insubstantial,
but I shouldn't have implied they all were.

> to explain why we come to different conclusions.

If we understand the differing perspectives,
we may find a mutually acceptable resolution.

> every PKI-enabled software there is, is another advantage.

Having a separate PKI for each certificate policy
requires duplicated infrastructure. Also, it
prevents cross-certification between organizations
with different certificate policies. This will
make it more difficult to build large PKIs.

So the merits of certificate policies are that they
allow one PKI to support multiple levels of assurance
and that organizations with different certificate
policies can cross-certify. The primary drawback
is greater complexity, I believe.

> "challenge" requirements as we are talking RFC3280 subsets.

I wasn't talking about a subset of RFC 3280. RFC 3280
does not require applications to provide UI for setting
all of the parameters specified in RFC 3280. If they're
appropriate and relevant to the application, they
will be exposed. Otherwise, they probably will not be.

All of the features of certificate policy processing
per RFC 3280 (including anyPolicy and such) can be
supported by providing UI for entering a set of policy
OIDs (as described by David) and three boolean flags:
initial-policy-mapping-inhibit, initial-explicit-policy,
and initial-any-policy-inhibit. It's up to an application
developer whether they want to expose these parameters
and, if so, how (through a dialog box, a configuration
file, or whatever).

Clearly this is a "compliant management interface" for
specifying all the parameters needed for RFC 3280-compliant
policy processing. I claim that I passed the "challenge",
but I still decline the "prize". ;-)

Thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Jan 2004 16:40:07 -0500

Steve,

I'll add to your discussion of motivation for policy OIDs, at no 
additional charge.

In principle, one could accomplish a similar effect by mandating use 
of a different CA name for each distinct policy used by the same CA, 
and by propagating knowledge of the policies bound to the names. 
However, this is a poor alternative in that it provides no easy way 
to convey the policy info when it is replicated by multiple CAs. of 
course we don't have enough examples to know if policies will be 
replicated, or replicated with caveats, as allowed for by policy 
qualifiers, but at least one can understand why it is more attractive 
to be able to represent this info via OIDs.

Talk of "trust administrators" just confuses matters. In an 
enterprise environment security administrators, are already concerned 
about the proper configuration of firewalls, VPNS, anti-virus rule 
sets, etc. The management of trust anchors and policies for PKIs is 
just another set of security-relevant data that these folks need to 
manage.  One major attraction of SCVP is that is allows 
centralization of this management function for TAs and policy info, 
rather than having to do this on every desktop and server.

If a vendor of a product that makes use of PKI fails to provide 
appropriate management interfaces for dealing with policies, I don't 
view that as a condemnation of the facility. If users don't see how 
to use the feature, especially in light of a lack of management 
interfaces, or confusing management interfaces, that too is not an 
indication that the feature is not useful. The perception users 
develop of the complexity of a feature is greatly dependent on the 
management interfaces provided, not the intrinsic feature. Anyone who 
has had to deal with programming a VCR, and who then moved to a TiVo 
or Replay system, can attest to the truth of this observation.
Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 29 Jan 2004 09:04:35 +0100

Steve & Steve,

>I'll add to your discussion of motivation for policy OIDs, at no 

That was nice to hear, my funding for external consultants is close to zero :-)

>to be able to represent this info via OIDs.

This is interesting.  I actually fully agree!

However, this is a rather different story than having multiple policies
per CA, engraving policy OIDs in EE certificates, and become
dependent on application dependent policy filtering.

>rather than having to do this on every desktop and server.

I have no problems with that.  I may even "upgrade" my terminology
if it makes you happier!

>management interfaces provided, not the intrinsic feature.

Here we obviously have different views.  I think Masaki SHIMAOKA's
(albeit also "homebrewed") terms Public PKIs and Private PKIs in his 
   "Memorandum for multi-domain PKI Interoperability" 
well depicts the scope of the two different approaches.  But who wants
to be private (=isolated)?  The US governments apparently do.

Regarding the policy system itself, I find this scheme odd.
The path-validation algorithm with respect to policies is the
most complex thing I have seen in my entire IT-life (30y+), while a
policy itself should according to RFC3280 be expressed as a single OID.
That is, anything ranging from, terms and conditions, certificate format, 
key container characteristics, to RA procedures, are lumped together,
making the OID pretty "user-hostile".  This deficiency forced the
RFC3039 authors to invent a competing policy system, called
qcStatements that requires it own policy admin GUI etc, and is
supposed to be added as an extra pass after standard path-validation.
This don't bode well for the future.

Anders

---

From: "Peter Hesse" <[email-masked]>
Date: Thu, 29 Jan 2004 10:04:31 -0500

I'll take the bait and throw this idea out there for you all to think about.
It's not entirely my idea, it is based on ideas discussed with Dave
Fillingham over the years.  Let's assume for the moment that you're working
with a PKI with a few different certificate policies in use; they might be
hardware/software stored keys, or high/medium/low assurance.

It is my suggestion that for a majority of PKI-enabled products with user
interfaces, the best solution may be to do the following:

A) Provide an administrative interface to map certificate policy OIDs to
human readable names, and potentially human readable descriptions of the
policies as well.

B) When building/validating certification paths, set the initial-policy-set
to any policy.  When a path successfully validates, display the signature
and validation status to the user, along with the human readable names for
the policies in the authority-constrained-policy-set, or an indication that
the path was not valid under any known policies.

If these steps are followed, the user can just be informed that the message
they received was valid for "Gemini medium assurance" or something like
that.  Not much difficulty to implement, nor would it be too difficult to
educate the users.

Now, assume we're dealing with a PKI larger than a single organization,
where there are differing certificate policies and appropriate certificate
policy mappings in place.  (Such as a Bridge CA environment.)  I'm assuming
in this case that all certificates that I want my relying parties to accept
would have certificate policies asserted.  In this case, we add just two
more steps:

C) When validating paths, set initial-explicit-policy to TRUE, to ensure
that only paths valid for a policy would be accepted.  (Or, set
requireExplicitPolicy through policyConstraints extensions in domain or
cross-certificates.)

D) Provide users with a switch to enable/disable
initial-policy-mapping-inhibit.  This may be referred to as "allow only my
organization" and "allow other organizations".  I'm presuming that
cross-certificates would fail to validate if require-explicit was true and
policy mappings don't take place.

Likewise, even if I received a message from a user from a different
organization, I would simply see that the message validated and that it was
valid under the "Gemini low assurance policy" or something similar.  This
doesn't add much implementation difficulty (assuming a compliant path
processing system) or make it too confusing for the user.

Just my $0.02.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius