Subject: Re: Straw poll: An advice to a commercial CA

From: [email-masked] (Peter Gutmann)
Date: Fri, 28 Nov 2003 00:27:25 +1300

Anders Rundgren <[email-masked]> writes:

>Assume that you as PKI professionals would advice a commercial
>TTP CA on how to configure their issuance for the following:
>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>2. Expensive (high insurance level) multi-usage certificates for individuals
>using strong verification procedures.
>
>Note: the service is to be launched ASAP and has the only
>objective, making money by serving its subscribers well.
>
>Indicate your advice by the word in uppercase.
>
>SINGLE: A single root + possibly some CP OIDs to spice things up
>MULTIPLE: Different roots

I'm going to have to qualify my answer by saying that it'd differ whether I
was acting for the CA or the RP, and whether it's an open or closed
environment.  If it's a closed environment I'd let them do whatever they feel
like and whatever the software supports (that is, find out what their software
will let them do, get them to test it to make sure it really does what the
vendor claims it does, go a few rounds with the vendor to make it actually do
what they claim, and then let them go with what they're comfortable with).
Since they don't have the option of changing the software, they'll have to do
what they can with what they've got.

If it's an open environment then given the almost complete lack of support for
policy restrictions and management (as Anders has pointed out), I'd tell them
to go for multiple CAs and handle it via the trusted-roots mechanism, which
pretty much everything supports.  Oh, and I'd probably have to sit through
interminable discussions with lawyers about how to word the CPS so that they
can do whatever they want to the RP without assuming any liability.

To answer an earlier question about support for policy restrictions, cryptlib
supports these (policy constraints with all its weird variations).  If
cryptlib finds constraints in a CA cert it'll apply them down the chain, but
there's no way for a user to configure the behaviour.  The reason for this is
that no-one has ever asked for this [0], so I can't even begin to imagine what
sort of interface it'd require to manage things.  Do users type in a list of
OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
policies advertised by this CA"?  Can you apply different policies to
different sets of certs?  Do you require the user to have read the policy (via
the URL) via a click-through mechanism before they enable its use?  What if
someone runs a MITM on them when they do this?  (It's most amusing that the
logotype draft has hashes to stop someone changing the inconsequential logo
that they see next to the cert, but there's nothing to prevent someone being
sent a completely bogus legal agreement when they ask for the policy).  If the
cert happens to use HTTPS for the policy (I've seen one or two that do), what
policy do you use for the cert securing the HTTPS transfer?  What happens if
the CA asserts anyPolicy but has a URL pointing to a very specific policy that
isn't anyPolicy?  What about qualifiers, do users have to agree to all of
those as well?  What are the policies applied for qualifiers, given that
there's only a single policy URL present?  Do you have to apply qualifiers
when applying policy constraints?  If not, why are they there?  etc etc etc.

Once all that is clearly defined somewhere, I can add support for it to my
code.  Until then, the policy extension serves best as a legal defence
mechanism for the CA to protect themselves from RPs, as per the legal analysis
I posted a day or two back.

Peter.

[0] Since cryptlib is open-source, it's quite possible that users have made
    custom mods to it to handle this, but I wouldn't hear about it unless they
    have problems.  I know that there are quite a number of customised
    versions in use in Europe to handle national signature law/regulation
    quirks (the fact that no government can resist adding its own incompatible
    changes to the legislation is a great help for OSS PKI software, because
    no commercial vendor can support it out-of-the-box), but no-ones ever come
    to me with questions about policy constraints.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 27 Nov 2003 15:02:56 +0100

>If cryptlib finds constraints in a CA cert it'll apply them down the chain, but
>policies advertised by this CA"? 

Oh Peter, now you become far too practical for _this_ list!

But it is indeed a real challenge to write a GUI to be used by
ordinary IS administrators, for a mechanism that you need a Phd
or better to grasp!

I guess you can wait with the GUI as long as Microsoft will
wait with a GUI in their products.  That is, forever.

Eureka, I got it!  Since this is black magic anyway, Microsoft
could make this configurable with Regedit!  That's how MSFT
usually treat stuff that you really shouldn't muck around with
at all or only on your own risk.  Finally RFC3280 has found
its true sole-mate.  It was a long journey...

Anders

---

From: Christine Karman <[email-masked]>
Date: Fri, 28 Nov 2003 14:16:42 +0100

>policies advertised by this CA"?

Typical users hardly know what a CA is. They don't know what kind of 
policies you are talking about. So a GUI would assume a most probable 
strategy, and then prompt the user with "I recommend you adopt policy xyz 
for this certificate. Press 'OK', or press 'advanced' to change". On a 
company level, a system administrator would force a certain behavior of the 
GUI, which cannot be changed by individual users.
Having said this, the GUI would probably make the choice by itself, because 
user interaction suggests that the user makes a decision on the subject, 
while in reality the user just presses a button that may as well read 
"Whatever".
I agree, this is not what the world should be like. But it is.

dagdag
Christine
--
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

---

From: Christine Karman <[email-masked]>
Date: Fri, 28 Nov 2003 14:16:42 +0100

dagdag
Christine

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 27 Nov 2003 15:02:56 +0100

Anders