RE: Yes, and remove more of the alphabet from the PKIX soup

["Phillip M Hallam-Baker" <pbaker@xxxxxxxxxxxx>]

> > I hope that means future CMP work is limited to incremental
> > fixes and improvements rather than competing with CMC
> > enhancements. Is this the case?
> > 
> These protocols need not be viewed as competing at all.  Many that I have
> spoken with seem to share the view that CMP is currently the 
> clear protocol
> for many enterprise environments,

I'm not particularly keen on this mode of argument, sourcing opinions
to anonymous sources does not seem quite fair. In any case many folk 
I have spoken to are under the influence of all sorts of bizare beliefs,
if we are meant to reject 'Popes, Kings and voting' then perhaps
we can also leave out unsourced opinion polls?


> CMC, on the other hand, may well mature to be the clear
> protocol for the Internet, along with some other repository technology
> (perhaps DNS), some other revocation technology (perhaps OCSP), 
> etc., etc..

I think that this is Bill's point. CMC is the IETF incarnation of the
protocol which is already the de-facto Internet protocol. Providing
the working group does not break backwards compatibility in the
standard drafting process it appears that CMC will be the Internet
standard.

Which is not something I would have expected you to accept since the
mandate of the Internet Engineering Task Force is limited to the 
standardization of Internet protocols.

If you can provide concrete suggestions for how we can overcome the
undefined shortcommings you see in CMC you should send them to the
list. The historical precedent has been that Internet protocols
trump those which are limited to 'enterprise' scope - for the 
obvious reasons of vendor interoperability and the fact that most
intranets turn out to have multiple domains of administrative
control, thus making them Internets.


I don't understand the point you are making regarding DNS and OCSP.
Clearly OCSP is one option for certificate revocation - but nobody
is suggesting that if you use CMC then you must also use OCSP. 
Equally there is no bar to users of CMP using OCSP (except to the
extent that the only vendor of CMP products does not at 
present support OCSP).

Nor is anyone proposing that DNS is an alternative for X.500/LDAP,
DNS is not a certificate repository! The issue is where the boundary
between the name space and the repository should lie. My argument
is simply that whatever means you choose for your certificate
repository (X.500, LDAP, HTTP, a custom kludge), that DNS should 
allow the location of the relevant certificate repository for a
DNS name. Again the issue is at least equally relevant to CMP.


		Phill