[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Certificate Policies (was Re: Trivial PKI Question)
Apparently, this email (which I sent yesterday) was not
posted to the PKIX list. I am resending it now. Apologies
for any duplicates.
-Steve
-------- Original Message --------
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
Date: Tue, 11 Mar 2003 17:18:40 -0500
From: Steve Hanna <steve.hanna@xxxxxxx>
To: Anders Rundgren <anders.rundgren@xxxxxxxxx>
CC: Santosh Chokhani
<chokhani@xxxxxxxxxxxx>,chris.gilbert@xxxxxxxxxxxxx, ietf-pkix@xxxxxxx
References: <>
<3E6DFDE7.5F56F42D@xxxxxxx> <>
Anders Rundgren wrote:
> We apparently do not agree on the value of policy extensions
> in certificates.
Yes, so it seems.
> >If we refuse to work on anything that's not already
> >widely deployed, we'll have to stop all innovation.
>
> Even if the method described in my previous message already is
> deployed, pretty universal, and works with all existing software?
The method you described (having a separate CA network
for each policy) is cumbersome. So, yes, I do think we
should work on getting support for certificate policies
into relying party software.
> X.509 Attribute certificates have also been touted as an
> important addition to PKI technology. I don't think even the
> authors believe that anymore. At least not in private.
Stop taking unsupported potshots at other technology.
It doesn't help your case.
> >Instead, we must continue to address real problems with
> >real solutions. If customers see value in these solutions,
> >they will be implemented by vendors.
>
> But how are they going to rollout this particular stuff?
> StarOffice will add such settings? It seems to me to be
> yet an additional way to fail with PKI.
I think you're asking how end users will configure which
certificate policies they want to require. I suspect that
there will be some button labelled "Advanced" or some
configuration file where they will specify this. But most
users won't use this feature, just as they don't use any
of the security-related user interface. They'll just use
whatever their system administrator has configured. Which
should be fine. Some programs (like email applications)
may have an option to display the certificate policy
associated with the sender (mapping it to a string like
"High Security" via a configuration file).
Another important way that these policies might be used
is that server software might require a "High Security"
certificate policy for clients or peer servers.
And, of course, you managed to slip in another negative
comment about PKI. Again, this does not advance your argument.
> >Certificate policies have definite utility. Several communities
> >are piloting their use, such as the U.S. Government.
>
> Although government PKIs like to position themselves as being
> in the forefront technically, I believe they are only in the
> forefront in terms of complexity and costs. If they had
> considered using high-level PKI models, they would never have
> had to use bridge CAs either.
An ad hominem attack.
I suggest you focus your attention on making a convincing
technical argument. So far, the only argument I have heard
from you is that certificate policies are complicated and
not supported by most current software. Therefore, people
should set up a separate CA network (or hierarchy) for
each policy. That's not very convincing.
-Steve