Subject: RE: OCSP-X vs SCVP

From: Frank Balluffi <[email-masked]>
Date: Wed, 15 Nov 2000 07:25:00 -0800

Phil,

It might be useful to be able to control the level of "opaqueness". For
example, a certification path validation protocol might want to include XML
extensions in its requests and responses, but treat certificates, CRLs and
OCSP responses (which may also include extensions) as "opaque" DER-encoded
elements.

Frank

> -----Original Message-----
> From: Phillip H. Griffin [mailto:[email-masked]]
> Sent: Sunday, November 12, 2000 12:46 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: OCSP-X vs SCVP
> 
> 
> 
> > 
> > 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
> ------------------------------------------------------------
>

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Thu, 16 Nov 2000 07:43:44 -0500

> OCSP responses (which may also include extensions) as "opaque" DER-encoded

Frank,

There are many approaches that can be taken. I seek to
create a general purpose capability, one that allows
XML to be used on both ends of the line with efficient
encoded binary in between; one that allows end to end 
text in a canonical form; one that allows an XML only 
client to communicate through a firewall to a server 
that can process requests and responses in either text
or binary; one that allows developers to display all 
ASN.1 values using markup when debugging.

But this approach will surely not solve all problems.
I imagine that often it will be useful to include XML 
payloads in ASN.1 encodings. Extension and attribute
XML payloads surely. And consider the following:

   Response ::= SEQUENCE {
      rc   INTEGER,
      msg  OCTET STRING (CONTAINING UTF8String 
                            ENCODED BY xml) 
   }

This constraint reveals the structure in an octet
hole as containing unicode and the xml OID can be 
used to signal further processing of the value in
the opaque string. Of course, a parser or coder 
tool can simply choose to ignore the constraint
as well, and treat msg as a simple opaque string.

When this piece of XML needs to be protected, there
are no white space or line feed considerations on
either end of the line. The markup can simply be
treated as an opaque value until it needs to be
displayed or further processed as an XML entity.

Phil