Re: OCSP-X vs SCVP

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

David,

<snip>

> The idea of a standard XML schema is that each protocol would *not*
> need to specify how to translate one to the other.  Every protocol
> would use the same translation.
> 
> The protocol document ensures that the ASN.1 and the XML specifications
> are equivalent (by mechanically generating one from the other), and
> once that is done, the VB programmer doesn't have to know jack about
> ASN.1 in order to write an application which exchanges data to and from
> an ASN.1 application operating in text mode!

I may be off-track but I don't see how you can generate an XML shema from an ASN.1 spec
without having an "ASN.1-shema".  Or was the idea that the protocol document is
an XML schema only?  On-the-wire format, would it be XML *or* DER?
I see no point in doing that.

> Anders seems puzzled that his suggestion to discard ACs and replace
> them with something written in XML was not warmly received, but that
> specifying SCVP etc in both ASN.1 and XML seems to be getting more
> support.  This is not puzzling; the former involves inventing something
> 'equivalent' from scratch, whereas the latter involves first
> standardizing the information to be exchanged and then writing two
> equivalent ways of encoding that information.

Actually I don't sugggest that an 'equivalent' XML implementation is to be
created.  A brand new scheme is what I believe is needed.

One reason for wanting ACs to use XMLDSIG is to be able to specify the specifc
local/global/national/application/whatever attribute profile as an XML schema.
Because unlike PKCs the variation in ACs is virtually unlimited which makes this "feature" extremely critical.
And also unlike PKCs the exact interpretation of virtually all fields is probably a requirement in just about
all likely applications.  <<<< I.e. an AC is really a "message" to be acted upon >>>>

OK, you *can* represent the entire AC attribute part as *one* XML schema but that
is IMO to use XML the wrong way as it leaves practically all interpretation (guesswork) to
the application layer.  Using a *specific* named schema for each profile things gets much easier.

Another reason to use a "self-contained signed attribute container object" instead of
defining a "certificate" is that you eliminate the need for direct protocol support of things like
cert-path information which could be critical given the "lukewarm" interest to change TLS etc.

And certificates stay in current PKC form (XML or ASN.1).

Using XMLDSIG, ACs would be "yet another business message profile" riding on top
of what others are aleady building, instead of a separate infrastructure.

How do you anticipate that ASN.1 ACs should be differentiated and read (identified, parsed, and
checked for correctness vs a specific profile definition) by verifier software?

With XML schemas, this is already in place without any plumbing at all.
Either the verifier application recognizes the specific AC profile as indicated by the schema
or not.  I see no such possibility with ASN.1 without requiring constant updates of
the reader/parser part.

I.e. to *me* the XML-schema-route is a one-way street with no easy (automatic) turning back.

Regards
Anders