Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)

From: [email-masked]
Date: Wed, 11 Feb 2004 14:13:46 +0000

Anders,

> I claim that current PKIX standards poorly support such scenarios
> as they have primarily been designed with "owners" in mind.

I support you in that they have been designed such that they permit
the owners to represent themselves in so many different,
inconsistent and sometimes contradictory ways that the end-user
community may struggle to interpret the various and many trust
domains to which they might subscribe.

I have argued in the past for a simplification of PKI and I will
continue to do so. I do not support, however, the addition of
detail that is merely a flavour of something that already exists
within the standards, even if it is a more simplistic and
easy-to-use representation. I favour a narrowing of the range of
plausible valid combinations within the existing rules, which I
believe can accomplish the same thing. I believe the current
standards adequately support 1:N maps between CA and policy and
that there are far greater barriers to widespread PKI uptake (eg.
Lack of unified X.500 naming space) than this.

Regards

Chris

**********************************************************************
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this communication.
If you have received this in error, please contact the sender and then
delete this email from your system.
**********************************************************************

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 12 Feb 2004 10:32:08 +0100

> I do not support, however, the addition of
>easy-to-use representation.

So you really mean that there WILL be a LIMITED SET of
UNIVERSALLY globally accepted policy OIDs that effectively
replaces CP documents?  And COTS application will be
pre-programmed accordingly?

If this interpretation is correct I can only say: Dream on.

My "dreams" are based on the fact vendors SHOULD NEVER
*have* to agree on things they consider "their own business".  Policy is
definitely (unless the UN is involved), community or business defined.

And there are MANY communities and businesses!

This is why the policy system [on a wider scale] is likely
to end-up as the global X.500 directory, as a "vision".

This is also why I insist recommending single-policy CAs
as they are independent of  "dreams" and "visions", they just
work.  Albeit at a premium for the owner.

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 12 Feb 2004 13:08:24 +0100 (CET)

In message <017201c3f14b$16b6b620$0500a8c0@arport> on Thu, 12 Feb 2004 10:32:08 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> >I do not support, however, the addition of detail
anders.rundgren> >that is merely a flavour of something that already
anders.rundgren> >exists within the standards, even if it is a more
anders.rundgren> >simplistic and easy-to-use representation.
anders.rundgren> 
anders.rundgren> So you really mean that there WILL be a LIMITED SET
anders.rundgren> of UNIVERSALLY globally accepted policy OIDs that
anders.rundgren> effectively replaces CP documents?  And COTS
anders.rundgren> application will be pre-programmed accordingly?
anders.rundgren> 
anders.rundgren> If this interpretation is correct I can only say:
anders.rundgren> Dream on.

I agree with "Dream on", and I've got a question for you: what makes
you think any policy OID would *replace* CP documents?  Do you imagine
that there would be some kind of magic policy OID that is implicitely
understood as far as responsabilities and liabilities and so on go?  I
can't recall anyone talking about any replacement here, and I'd
suspect that noone would.  I dunno about you, but I'm not ready to
take any policy OID on a "carte blanche" basis.  I wanna read what it
means.  To compare with a real-world example, how many do you think
would want to handle a credit card without that sheet of legal terms?
As you said: dream on...

anders.rundgren> My "dreams" are based on the fact vendors SHOULD
anders.rundgren> NEVER *have* to agree on things they consider "their
anders.rundgren> own business".  Policy is definitely (unless the UN
anders.rundgren> is involved), community or business defined.

Yes?  To get back to certificates, what would make a business have to
agree on someone else's policy (except in a cross-certification case,
but that is rather about policy mappings than agreeing to use someone
else's policies...)?

anders.rundgren> And there are MANY communities and businesses!

Yes?  I don't exactly see that as a problem per se.  I *do* see the
policy=CA thought as a problem, though, as that only increases the
pletora (sp?) of choices and definitely complicates communications
between the communities and businesses...  or for the users with their
communities or businesses, for that matter...

anders.rundgren> This is why the policy system [on a wider scale] is
anders.rundgren> likely to end-up as the global X.500 directory, as a
anders.rundgren> "vision".
anders.rundgren> 
anders.rundgren> This is also why I insist recommending single-policy
anders.rundgren> CAs as they are independent of "dreams" and
anders.rundgren> "visions", they just work.  Albeit at a premium for
anders.rundgren> the owner.

I'd say that they kinda work, right now, in form of closed communities
and businesses (come on, since when can you, as a VeriSign certificate
recipient, verify a Thawte (uhmm, they're still using their own roots,
right?) certificate, having only the VeriSign roots as trust anchor?
Until you can, VeriSign is a close community, as is Thawte, as is...).
When you start to have communication across CA borders (and I'm
thinking cross certification would be the tool of choice), having
fewer roots to cross-certify is a good thing.  And if you're thinking
of just having an increasing list of roots in your software, just
think how hellish it will be for *every* user or administrator
everytime a new CA pops up just because some company sets up a new
policy.

But then again, we don't have the kind of communication across CA
borders that I'm talking about (and according to pessimistic voices
never will, since we don't have it today) yet, so it's true, today it
"works"...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 12 Feb 2004 13:49:39 +0100

>means.

Here you "policy-OID-zealots" lose me completely.  Assume that you
are in the situation where you have to decide whether you are going
to accept a new trust anchor or not.  Then you [maybe] read the CP
and make the decision to "trust" this and installs the trusts anchor.  If
the trust anchor represents a single policy CA, you don't have to bother
about anything more.

>And if you're thinking of just having an increasing list of roots
>in your software, just think how hellish it will be for *every*
>user or administrator everytime a new CA pops up just because
>some company sets up a new policy.

This is based on the rather speculative idea that CAs add policies
at their wim.  But if policies are NOT standardized users still get
the  very same problem: a blocked communication channel. 
This is what makes people REALLY upset and RIGHTFULLY
wanting that userid/password stuff back, as it had no legal issues,
no policy "crap", and you can just phone it to the other guy.

I believe this situation will limit the applicability of multi-policy
CAs considerably.

Agreeably, I work with open scenarios where competence is
zero or below.  It is challenging in its own mysterious ways...

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 12 Feb 2004 15:15:14 +0100 (CET)

In message <001c01c3f166$ba19b130$0500a8c0@arport> on Thu, 12 Feb 2004 13:49:39 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Here you "policy-OID-zealots" lose me completely.

Hmm, that's the first time I've been called a zealot.  Is that good or
bad?  :-)

anders.rundgren> Assume that you are in the situation where you have
anders.rundgren> to decide whether you are going to accept a new trust
anders.rundgren> anchor or not.  Then you [maybe] read the CP and make
anders.rundgren> the decision to "trust" this and installs the trusts
anders.rundgren> anchor.  If the trust anchor represents a single
anders.rundgren> policy CA, you don't have to bother about anything
anders.rundgren> more.

Hmm.  An example: say there's a business that deals with fairly
expensive stuff, and will therefore only deal with people that can
show they have a minimum credit limit of $100k.  They can verify
certain certificates that correspond to the Silver ($10k limit),
Gold ($100k limit) and Platinum ($1M limit) policies.  To have their
software work with this, they need to configure it with information on
what kind of data is acceptable.  As far as I can see, here's how they
would handle it:

 1. the policy=CA scenario: install the "O=Foo Inc, OU=Platinum CA"
    and "O=Foo Inc, OU=Gold CA" root certificates.
 2. the multi-policy CA scenario: install the "O=Foo Inc, OU=CA" root
    certificate and the policy OIDs corresponding to Gold and
    Platinum.

Not much of a difference, really.  Now, suppose Foo Inc adds a
Kryptonium policy with a $10M credit limit.  Of course, our example
business wants to include people with that kind of credit policy among
their customers (they would hardly say "you have too high a limit, so
we can't trust you").  To do that, they would have to perform one of
the following actions:

 1. add the "O=Foo Inc, OU=Kryptonium CA" root certificate among the
    already installed ones.
 2. add the Kryptonium policy OID among the already installed policy
    OIDs.

Not difference at all.  After all, to do this at all, they have to be
informed, one way or another, that there's a new policy and what
pieces of data come with it.  And either way, don't you think that our
example business would like to know the conditions applied to the new
policy, i.e. read some kind of policy document?  How are things like
this handled with credit cards today?  Am I about to be desillusioned?

I really don't understand how the scenarios above would be performed
without some kind of human action and awareness.  I doubt "magic" is
an appropriate response...

anders.rundgren> >And if you're thinking of just having an increasing
anders.rundgren> >list of roots in your software, just think how
anders.rundgren> >hellish it will be for *every* user or administrator
anders.rundgren> >everytime a new CA pops up just because some company
anders.rundgren> >sets up a new policy.
anders.rundgren> 
anders.rundgren> This is based on the rather speculative idea that CAs
anders.rundgren> add policies at their wim.  But if policies are NOT
anders.rundgren> standardized users still get the very same problem:
anders.rundgren> a blocked communication channel.

Uhmm, I wasn't really implying "at their wim", but you can't really
deny that policy changes and additions DO happen, and when that
happens, there is some new information that you will need to deal with
if you want to bother with the changes or additions at all.

anders.rundgren> This is what makes people REALLY upset and RIGHTFULLY
anders.rundgren> wanting that userid/password stuff back, as it had no
anders.rundgren> legal issues, no policy "crap", and you can just
anders.rundgren> phone it to the other guy.

Are you talking about people like users or people like business
administrators?  I can fully understand that your regular J. Random
User doesn't give a crap about policies more than possibly the pamflet
he gets to read when he got his brand new credit card (most people do
not read that either).  I don't expect J. Random User to check the
policies that come with the certificate served by https://foo.com/.
However, if Random Bank Inc does business with all kinds of customers
and use the customers' client certificate for authentication and other
checks, I would be *really* surprised if they wouldn't want to know
what credit limits come with those.  Things like credit limits would,
as far as I can see, come as part of the certificate policy in those
client certificates.  I'm quite sure that bank *does* care about such
stuff.

Of course, the bank example requires either that they have done a bit
of cross certification with credit companies or other banks, or that
their customers all have certificates issued by said bank.

But of course, that bank can as well use userid/password and have the
rest in a database.  It's all part of what you believe in and if you
want to be able to use information coming from other sources or not.

anders.rundgren> I believe this situation will limit the applicability
anders.rundgren> of multi-policy CAs considerably.

I think that your scenario may limit the applicability of X.509/PKIX
at all, just as much as multi-policy CAs.

anders.rundgren> Agreeably, I work with open scenarios where
anders.rundgren> competence is zero or below.  It is challenging in
anders.rundgren> its own mysterious ways...

Now, *that* is something I agree with, and I do believe that those of
us that feel they have enough competence have a more or less implied
role as educators.  Of course, one has to be willing to educate in the
first place...

-----

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 12 Feb 2004 11:15:41 -0500

Competitive enterprises have been known to cooperate
and agree on standards, both commercially-developed
(Beta / VHS / MiniDV / DVD-RW / DVD+RW / DVD-RAM for
video, 802.11b / 802.11g for wireless networking)
and government-sponsored (FIPS 140-2 Level 1/2/3/4
for crypto modules, 87/89/91 octane for gasoline).
Joe Sixpack doesn't need to understand the technical
details on any of these standards; he just needs
to know what media is compatible with his player
or what gas is compatible with his car.  That's the
point of standards.

Certificate Policy can be both business-defined and
standardized; they are not mutually exclusive.  All
that is required is for an initial coalition of vendors
to demonstrate competitive advantage by standardizing.
Additional vendors will then either join the first
camp or form other camps.   Or, more likely, the
catalyst for standardization will be government or
commercial certificate consumers (automobile, aerospace,
etc) rather than certificate producers.

Either way, policy standardization isn't going to be
justified by looking at one vendor and comparing the
effort to stand up one CA vs. (for example) four.
The leverage only happens when you look at four
community-developed policies and have N >> 4
independent vendors sign on to support (either
directly or via policy mapping) them.

Is this a dream?  Maybe.

Is it "policy zealotry"?   Of course not, but feel
free to call it what you wish.  It looks more like
"vision" or "leadership" to me.

Dave

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 12 Feb 2004 17:55:13 +0100

Richard,

Although technically possible, this use case does not match the
"VeriSign-like" scenarios I refer to.  They are about identity
and hardly anything else.

I also consider this way of stuffing certificates with potentially
dynamic information as unrealistic as credit-limit is a lookup
mechanism in most real-world scenarios.

If OTOH policies are rather used to indicate usage, security-
level etc. the administration of every unique Policy OID
will require the same care as the installation of a single
policy trust anchor.  But with more fuzz:

    root certificate.

 2. the multi-policy CA scenario: install the "O=Foo Inc, OU=CA" root
    certificate AND the policy OID corresponding to Platinum.

The Policy OID must be read in the CP and pasted into an
application specific dialog or command line as few existing
key admin tools supports this.  As do few trust store mechanisms
either which creates even more fuzz as the integrity of the trust
database is dependent on two *disjunct* systems.  Unless MSFT
and SUN augment their trust store mechanisms with policy OID
support, I remain highly skeptical about their commitment to
the policy OID system.  Outside of the PKIX list that is...

Anders

----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, February 12, 2004 15:15
Subject: Re: Policy User Interfaces

In message <001c01c3f166$ba19b130$0500a8c0@arport> on Thu, 12 Feb 2004 13:49:39 +0100, "Anders Rundgren" <[email-masked]>
said:

-----