Re: Certificate Policies

[Richard Levitte - VMS Whacker <levitte@xxxxx>]

In message <> on Fri, 14 Mar 2003 10:52:22 +0100, "Anders Rundgren" <anders.rundgren@xxxxxxxxx> said:

anders.rundgren> Hi Richard,
anders.rundgren> 
anders.rundgren> >A policy implies what is written in it (in the CP
anders.rundgren> >and the CPS).  There's nothing in a policy OID that
anders.rundgren> >can tell you what the function or the legality of
anders.rundgren> >the policy is, you have to read the documents and
anders.rundgren> >decide that for yourself accordingly.
anders.rundgren> 
anders.rundgren> So far, I am with you.
anders.rundgren> 
anders.rundgren> Now assuming that a single CA key/cert can create N
anders.rundgren> different policies applied to M different EE
anders.rundgren> certificates, you get a potentially unmanageable
anders.rundgren> legal/function matrix.

A CA key/ct doesn't create policies.  It may contain N different
policies, of which one (at least that's what I assume) will be used
every time an EE certificate is issued.  I don't quite understand why
that would create such a matrix, does the policy change from one EE
certificate to another?  The way I see it, you keep track of N
policies when validating a path, period.

It sounds like you're creating problems where there aren't any, or
there is something that I haven't quite grasped yet...

anders.rundgren> BTW, why do some people believe that you need a lot
anders.rundgren> of different policies?  To keep legal departments
anders.rundgren> busy?  Why do you actually need more than one within
anders.rundgren> a given "trust-network"?

More than one is obvious.  You may a have different policy for EE
certificates given to people who are supposed to use them for million
dollar transactions than the one for EE certificates given to mail
users.

Why everyone seems to need to have their own "special" policy?  Beats
me.  Why do we have all those different program licenses that
essentially express the same thing?  Why do commercial programs come
with licenses written uniquely by each vendor?  Why can't they agree
to use the exact same license?  Why does each company have it's very
own contract form for employees instead of using a standard one?

I believe the answer is "welcome to the human condition" rather than
anything really rational, perhaps except that many CPs are written for
one specific CA (mentioned by name and so on) and is therefore not
usable for other CAs.  In any case, it's a matter of keeping control
over the stuff you use and produce, and I agree that it takes silly
proportions in this case.

If you write a set of CPs and submit them to some kind of standards
commitee (I think NIST has collected a few CPs), and I like them, I've
no problem with using them instead of writing my own.  If someone else
does the work and allows me to use the work in question, why should I
waste my time redoing the work?

anders.rundgren> It would be very interesting to see what purposes all
anders.rundgren> this stuff is supposed to fill in application software.
anders.rundgren> 
anders.rundgren>             Architecture?
anders.rundgren> 
anders.rundgren>             Data model?
anders.rundgren> 
anders.rundgren>             Links?

You keep on saying that, and you seem to forget there's a human side
to this as well.  There are people with needs of control.  I believe
that's the answer to your question much more than a programmatic one.

anders.rundgren> I occasionally look on this in a slightly
anders.rundgren> "philosophical" way:  If one large user like DoD,
anders.rundgren> deploys "something" but the rest of the market does
anders.rundgren> not, using my thinking, it was a failure for this
anders.rundgren> "something" (and long-term also for the DoD).

Not really.  Within DoD and others that have used PKI for a while,
this is old stuff.  Among "common people", this is really new, and
most of them haven't even been told this exists...  It takes a while
before this becomes common knowledge.  It's almost like the Internet;
according to John Doe on the street, the Internet started somewhere
like 1994 or 1995, or perhaps even later...  It takes a while before
knowledge spreads...

anders.rundgren> As not even X.500 directories and LDAP are sacred anymore
anders.rundgren> http://www.imc.org/ietf-pkix/mail-archive/msg05571.html ,
anders.rundgren> it seems that PKI technology is still to be regarded as being
anders.rundgren> highly immature.  That is, your answer is as good as mine.

You couldn't have said it better.  It hasn't matured yet, and we're
all working to help it mature (or to reject it :-)).

anders.rundgren> Unless somebody provides some more facts regarding PE
anders.rundgren> usage in application software, I suggest that we halt
anders.rundgren> this thread a while, and let the market do the final
anders.rundgren> selection...

Let me think about usage a bit and I'll get back to you (if I
remember).

About letting the market decide, I'm not sure I trust it very much.
Most people have a tendency to go for something cheap that works for
now, often resulting in a status quo of crap (for some definition of
"crap").  I have very little trust in the market's lookout for
quality, I've just seen too few examples of that happening.  If I'm
wrong, I'll joyfully be corrected!

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