Re: OCSP-X vs SCVP

["Phillip H. Griffin" <phil.griffin@xxxxxxxxx>]

> 
> Certainly ASN.1 is older and parts are more stable, but it's also growing
> (and has grown -- PKIX1Explicit88, e.g.).  So is XMLSchema.  For the
> purposes of comparison, let's just call them equivalent.

But they are not. And you misunderstand. The module 
PKIX1Explicit88 is not itself ASN.1. It is one module
of one specification written using ASN.1. It is a 
collection of definitions based on ASN.1 types. The 
values of these types conform to both the structure
and rules for values defined by the ASN.1 standards. 

> 
> >If there were but one XML schema life would
> >be easy. But there are many XML schema, and
> >more seem to be popping up in various XML
> >communities.
> 
> That makes no more sense than saying there should be but one ASN.1 module.

No. An ASN.1 module is not a schema. 

But ASN.1 can provide a schema for markup values 
that are associated with ASN.1 type definitions. 
This association makes it possible for ASN.1 
applications to transfer values to and from XML
applications in a standard way. So ASN.1 can be 
used to define another set of rules, like BizTalk, 
DT4-DTD or XML-schema, for what constitutes valid
typed values. Markup is just another way to 
represent these values.

> 
> I'm not advocating that the IETF, the Security Area or the PKIX WG "use"
> XML (for some definition of use).  I am trying to show that the XML
> communities are working to define *everything* needed to describe and
> exchange data.  It might not make sense to use it -- I personally
> see little point in rewriting X.509v3 datatypes in XML-Schema -- but
> we should be aware of what's going on for if/when we do decide to work
> in that space.
>         /r$

Agreed. 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. 

So that for an arbitrary type definition, say

   MyType ::= SEQUENCE { 
      label  PrintableString, 
      value  INTEGER
   }

a value of that type can be decoded by a recipient (or
encoded and transferred by a sender) using the markup

   <MyType>
      <label> 
      </label>
      <value>
     </value>
   </MyType>

And so that a valid value of that ASN.1 type, a value
which conforms to the rules defined in the ASN.1 
standards, such as

   userValue MyType ::= { 
      label  "My shoe size is ",
      value  10
   }

can be encoded and transferred as either ASN.1 
encoded binary data or as the markup value

   <MyType>
      <label> 
         My shoe size is&nbsp; 
      </label>
      <value>
         10 
     </value>
   </MyType>

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
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------