RE: OCSP-X vs SCVP

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
>
> This will provide a means to extend the capability 
> deployed today - the ability to unambiguously encode
> and decode a value of an ASN.1 type. A standard markup
> for the ASN.1 notation will provide a new format for
> expressing the same ASN.1 values.
> 
> By binding a standard markup to the values defined as
> valid for ASN.1 types, it will be possible for an ASN.1
> application to send or receive ASN.1 values in either
> text or binary formats.

Phil,

This description does not do justice to the powerful advantages a
standard XML schema would provide.   See below.



> From: Dan Ash <daniel.ash@identrus.com>
> 
> I might be completely off track here, but is it possible, and does it
> make sense to include within the definition of a protocol not only
> different languages to represent the content,  but also a specification
> of how to translate from one language to the another?  If so,  perhaps
> some arbitrary software (independent of the client or the server) could
> translate from one language to another... allowing both the client and
> the server to deploy in either language.  This might alleviate the
> problems mentioned above.


Dan,

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!

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.  Applications can be
developed completely independently - XML developers use their favorite
tools to implement the XML protocol specification, ASN.1 developers use
their favorite tools to implement text mode encoding from the ASN.1
protocol specification, and the two applications work together.

I believe that PKIX should evolve to include both ASN.1 and XML
specifications of each protocol, and should require that those
specifications be equivalent for each protocol which includes
an XML specification.



> From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
> 
> What I am proposing is to modify the ASN.1
> standards so that the values of all ASN.1 types can
> be expressed using a common XML markup.

I agree.  But just as RFC 2459 includes both 88 and 92 appendices,
PKIX documents should include both ASN.1 and standalone XML appendices.