Subject: RE: What happened to the OCSPv2 draft?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Sep 2002 10:51:49 -0700

> > I fail to see the value of an XML expression of deployed
> > X.509 semantics. I fail to see the value of an ASN.1
> > encoding to rival deployed XML specifications.

> I see much value in X.509 semantics, regardless of the
> form of their expression. XML markup is just another
> encoding rule for ASN.1 values.

I still fail to see the advantage to an incompatible syntax
for an existing deployed standard.

ASN.1 is not such a barrier to deployment of PKI that any
party I am aware of is willing to forgo interoperability
with the deployed X.509v3 base just for the sake of being
able to avoid ASN.1 encoding.

The only justification for an incompatible data format is
if the standard is going to support substantially different
semantics that addresses a substantially different application
domain, in the case of XKMS the specification is service
oriented and the semantics are key centric as opposed to 
certificate centric.

I don't believe that there is the slightest possibility
that the Web Services community is going to adopt ASN.1
as a compressed encoding layer. XML and ASN.1 are both 
already complex enough without taking the cross product
of both.

		Phill

---

From: Phil Griffin <[email-masked]>
Date: Mon, 16 Sep 2002 16:01:46 -0400

Phillip,

> for an existing deployed standard.

You misunderstand my statement. X9.68 supports all of
the X.509 certificate payloads required in the ISO 15782
profile for the fincvs industry. But the format is not
the same as that in the deployed X.509 standard. But a
DER encoding of some 170 bytes in X9.68 can carry the
same information content as that found in an 11-1200
byte X.509 certificate.

> ASN.1 is not such a barrier to deployment of PKI that any

I would say that given the freely available tools,
ASN.1 is hardly a barrier to deployment.

> oriented and the semantics are key centric as opposed to 

In the case of X9.68, the certificate format is domain
centric and not identity centric - there are no DNs, and
each domain certificate name uniquely identifies that
certificate as well as all of the certificates needed for
path validation.

> already complex enough without taking the cross product

I'm sure that I am not alone in remaining hopeful that
the Web Services community will end up with viable,
efficient solutions that are simple and secure.

Phil