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

From: "David P. Kemp" <[email-masked]>
Date: Mon, 02 Feb 2004 15:21:39 -0500

One man's trash (or fuzzy decoration) is another man's treasure.

Peter Hesse described quite well the idea that there are the
rare PKI theologists who create policy mappings between domains,
a medium number of information owners who must understand
policies within their own domain, and a large number of
grandmothers, joe sixpacks, and soldiers who have no need to
know or care.

When you are outfitting 4.3 million people, you don't buy them
all $25 fuzzy dice if a plain $5 cert is good enough.  Do you
suppose the people who make DoD policy might have some cyber
threat information that makes them believe the extra cost is
worth it?  Do you suppose "policy=CA" just won't cut it in
an interoperable environment unless you force all
of your information owners to become high priests?

Peter Gutmann wrote:

> "David Cross" <[email-masked]> writes:
> 
> 
>>My grandmother just won't understand the meaning of "initial-policy-mapping-
>>inhibit" no matter how much she loves me.
> 
> 
> And therein lies the problem.  It's not just Joe Sixpack who can't understand
> any of this stuff, no-one apart from PKI theologists know (or care) about it.
> So the approach that a typical technical manager/administrator who has to work
> with certs will take is to use "policy = CA", with the Foo policy being
> implicitly enforced by having the cert issued by the Foo CA, and the Bar
> policy enforced by the Bar CA.  Going beyond private CAs (whose policy is
> usually an implicit "Whatever we say it is"), if you look at almost any public
> CA you'll see a pile of top- or intermediate-level CA certs with names that
> are some variation on "<CA-name> <policy-name> CA" (the most famous being the
> "Verisign Class X Blah CA" family) - it's the old PEM idea, but without the
> single root.  Policy constraints and enforcement and mappings and whatnot are
> just fuzzy dice that exist so orgs like the US DoD have something to decorate
> their certs with.
> 
> Peter.
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 3 Feb 2004 08:41:41 +0100

David,

I don't think that there is any disagreement whatsoever regarding the
utility of different policies, centralized administration of trust, and
end-user impact.

What is dividing us, is "only" how we believe that 1) multiple policies
should be applied to PKI, and 2) how these policies are supposed to be
handled by relying party applications and system administrators.

A condensed version of my point of view is as follows:

It may be beneficial to only use single policy CAs and then associate
relying party applications with different trust stores holding roots to CAs
with suitable policies.  At least if you intend to let your PKI extend
outside of your own premises.  It also means that relying party security
administration can be performed by a single tool, in a single place which
can contribute to improved security.  Applications do not have to know
anything about policies and OIDs, except that they of course no matter
what you do, typically act on certain subject attributes etc., like e-mail
clients look for e-mail addresses, and browsers look for DNS names.

In case you want more of this I'm currently writing a paper called
"Handling Multiple Policies in Certification Authorities"

regards
Anders Rundgren
Consultant, PKI & e-Business

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 3 Feb 2004 10:16:14 -0500

Anders,

	I think that there's general agreement with your statement

> with suitable policies.

	However, the key word there is "MAY".  Some people/organizations believe
that "policy=CA" is best for them.  Others (e.g., the Government of Canada
PKI, see my response to Peter's message) believe that "CA => 1 or more
policies" is better.  It depends on the requirements of the specific system.

	WRT your statement:

> "At least if you intend to let your PKI extend
> outside of your own premises."

	note that the US and Canadian Governments do have broad interoperability
requirements - in fact, they had to figure out how to interoperate with each
other.  That's one of the reasons that the US Government copied the "Bridge
CA" idea from the automobile industry - it made interoperability easier,
without having to rely on a single (third-party) CA.

	I'm not disputing that for your customers, and the organizations about
which you care, a single policy per CA is better.  That's fine.  But that
set of organizations does not make up the entire universe; it does not make
up the universe of those who have interoperability requirements; and it does
not make up the entire universe of those affected by the Internet/IETF.

	As I mentioned in my response to Peter G., there seems to be a thought on
your part and his to make support for certificate policies optional vice
mandatory.  If that's your proposal, fine; let's get it out there and see
who agrees with you.  But claiming that the policy structure doesn't work is
bogus; it's supported in enough environments to refute that. And given some
level of support for cert policies, I doubt you'd have any success in
throwing it out of 3280/X.509 altogether.

				Al Arsenault

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Tuesday, February 03, 2004 2:42 AM
> To: David P. Kemp; [email-masked]

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 3 Feb 2004 16:36:12 +0100

Al,

<snip>

>note that the US and Canadian Governments do have broad
>interoperability requirements - in fact, they had to figure out how 
>to interoperate with each other.  That's one of the reasons that the
>US Government copied the "Bridge CA" idea from the automobile
>industry - it made interoperability easier, without having to rely on
>a single (third-party) CA.

Governments' position:
- LDAP directories with certificates
- Employee-level PKI for inter-org comm.
- Cross certification
- Bridge CAs
- Expensive

The private sectors' position today
- No PKI except https server support
- shared secrets, leased lines and VPNs for inter-org comm.

The private sectors' position some time in the future
- Employee certificates are hardly ever used in inter-org comm.
- Org-level (mostly) TTP-based PKI secure inter-org comm.
- Some C2G services (tax declarations) require citizen certificates

I see some problems out there.  Policies is just a minor
"wart" in that not too tasty pudding.

Anders