Subject: RE: asn1xml Re: PKIXML session. Was: PKIX WG tentative agenda

From: Andrew Layman <[email-masked]>
Date: Fri, 8 Dec 2000 14:53:52 -0800

I just happened to skim this, and notice that the dates don't fit the
pattern called for by XML Schemas part 2.

-----Original Message-----
From: Phillip H. Griffin [mailto:[email-masked]]
Sent: Friday, December 08, 2000 12:10 PM
To: 'PKIX'
Cc: asn.1/xml
Subject: asn1xml Re: PKIXML session. Was: PKIX WG tentative agenda

Steven Legg wrote:
> 
> > -----Original Message-----
> > From: Aram Perez [mailto:[email-masked]]
> > Sent: Friday, 8 December 2000 4:25
> > To: PKIX
> > Subject: FW: PKIXML session. Was: PKIX WG tentative agenda
> >
> >
> > Just for fun, I've attached the PKIX example #1 certificate
> > converted from
> > ASN.1 to XML.
> >
> > Enjoy,
> > Aram Perez
> 
> That's one way to encode a certificate in XML, but not a method I find
> particularly appealing. The following XML encoding of the same certificate
> is my best guess (possibly way off) at what represents current thinking on
> the ASN.1 group's XML encoding rules mailing list. I would name the
elements
> in a SET OF or SEQUENCE OF differently, but that is an argument for a
> different forum.

Steven,

I can't speak for everyone involved in the ASN.1/
XML work, but this is a very good guess as to where
we seem to be headed. But there are many particulars 
still to be discussed and resolved and many different
opinions to consider. 

For example, the representation of OID values has
spawned a great deal of discussion. While I have
favored <tag>1.2.3.4</tag> that mimics the notation
used in LDAP, other prefer the ASN.1 value notation
format that you've used below. But there is also some
sentiment for relying on the urn:oid work currently 
being progressed in the IETF, as well as proponents
of the <tag>iso(1) identified-organization(3)</tag>
style format.

And that's just one small issue. The work plan has 
just been announced and is scheduled for 22 January
through 2 February 2001, in Geneva, Switzerland. For
anyone that is interested, they might wish to monitor
the discussion list at [email-masked], as the details 
of this work are probably a bit off topic for pkix.

I would comment though that the benefit of this new
notation is obscured somewhat by the examples being
used. Certificates are not very interesting to look
at for most humans in any format and seem to be at 
their best in a small, efficient binary format that
is mechanically processed. Only a few of their parts
have much use as display items. 

These examples do serve to illustrate how verbose tagged
text formats can be. But what will be more beneficial to
consider for ASN.1 users I believe, will be the ability
to generate default ASN.1 specified XML mark up for the 
likes of protocol messages, say perhaps the request and 
response messages specified in tools such as OCSP. 

Phil

> 
> <Certificate>
>   <toBeSigned>
>     <version>
>       v3
>     </version>
>     <serialNumber>
>       17
>     </serialNumber>
>     <signature>
>       <algorithm>
>          { 1 2 840 10040 4 3 }
>       </algorithm>
>     </signature>
>     <issuer>
>       <rdnSequence>
>         <RelativeDistinguishedName>
>           <AttributeTypeAndValue>
>             <type>{ 2 5 4 6 }</type>
>             <value>US</value>
>           </AttributeTypeAndValue>
>         </RelativeDistinguishedName>
>         <RelativeDistinguishedName>
>           <AttributeTypeAndValue>
>             <type>{ 2 5 4 10 }</type>
>             <value>gov</value>
>           </AttributeTypeAndValue>
>         </RelativeDistinguishedName>
>         <RelativeDistinguishedName>
>           <AttributeTypeAndValue>
>             <type>{ 2 5 4 11 }</type>
>             <value>nist</value>
>           </AttributeTypeAndValue>
>         </RelativeDistinguishedName>
>       </rdnSequence>
>     </issuer>
>     <validity>
>       <notBefore>
>         970630000000Z
>       </notBefore>
>       <notAfter>
>         971231000000Z
>       </notAfter>
>     </validity>
>     <subject>
>       <rdnSequence>
>         <RelativeDistinguishedName>
>           <AttributeTypeAndValue>
>             <type>{ 2 5 4 6 }</type>
>             <value>US</value>
>           </AttributeTypeAndValue>
>         </RelativeDistinguishedName>
>         <RelativeDistinguishedName>
>           <AttributeTypeAndValue>
>             <type>{ 2 5 4 10 }</type>
>             <value>gov</value>
>           </AttributeTypeAndValue>
>         </RelativeDistinguishedName>
>         <RelativeDistinguishedName>
>           <AttributeTypeAndValue>
>             <type>{ 2 5 4 11 }</type>
>             <value>nist</value>
>           </AttributeTypeAndValue>
>         </RelativeDistinguishedName>
>       </rdnSequence>
>     </subject>
>     <subjectPublicKeyInfo>
>       <algorithm>
>         <algorithm>{ 1 2 840 10040 4 1 }</algorithm>
>         <parameters>
>           <p>
>             d43802c5357bd50ba17e5d72596355d3
>             4556eae2251a6bc5a4abaa0bd462b4d2
>             21b195a2c601c9c3fa016f7986833d03
>             61e1f192acbc034e89a3c9534af7e2a6
>             48cf421e21b15c2b3a7fbabe6b5af70a
>             26d88e1bebecbf1e5a3f45c0bd3123be
>             6971a7c290fea5d680b524dc449ceb4d
>             f9daf0c8e8a24c99075c8e352b7d578d
>           </p>
>           <q>
>             a7839bf3bd2c2007fc4ce7e89ff33983510ddcdd
>           </q>
>           <g>
>             0e3b46318a0a58864084e3a1220d88ca
>             908857649f0121e01505942482e21090
>             d9e14e105ce7546bd40c2b1b590aa0b5
>             a17db507e3657cea90d88e3042e485bb
>             acfa4e764b780edf6ce5a6e1bd59777d
>             a69759c529a7b33f953e9df1592df742
>             87623ff1b86fc73d4bb88d74c4ca4490
>             cf67dbde1460974ad1f76d9e0994c40d
>           </g>
>         </parameters>
>       </algorithm>
>       <subjectPublicKey>
>         028180aa98ea1394a2dbf15b7f982f78
>         e7d8e3b97186f6802f4039c3da3b4b13
>         4626ee0d56c5a33a39b77d33c26b5c77
>         92f255659039cd1a3c86e132eb25bc91
>         c4ff804f3661bdcce26104e07e6013ca
>         c09cdde0ea41de33c1f144a9bc71decf
>         59d46eda44993c2164e478549dd07bba
>         4ef5184d5e3930bfe0d1f6f483254f14
>         aa71e1
>       </subjectPublicKey>
>     </subjectPublicKeyInfo>
>     <extensions>
>       <Extension>
>           <extnId>
>           { 2 5 29 19 }
>         </extnId>
>         <critical>
>           TRUE
>         </critical>
>         <extnValue>
>           30030101ff
>         </extnValue>
>       </Extension>
>       <Extension>
>         <extnId>
>           { 2 5 29 14 }
>         </extnId>
>         <extnValue>
>           0414e726c554cd5ba36f356895aad5ff1c21e42275d6
>         </extnValue>
>       </Extension>
>     </extensions>
>   </toBeSigned>
>   <algorithmIdentifier>
>     <algorithm>
>       { 1 2 840 10040 4 3 }
>     </algorithm>
>   </algorithmIdentifier>
>   <encrypted>
>     302c0214a066c176339913518d93642f
>     ca1373de791a7d3302145d90f6ce924a
>     bf2911248028a65a8e73b6760268
>   </encrypted>
> </Certificate>
> 
> Regards,
> Steven

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Fri, 08 Dec 2000 19:38:15 -0500

> pattern called for by XML Schemas part 2.

Andrew,

This is part of the reason that an alternative
to our initial schema mapping approach has been 
proposed and why schema mapping has lost some of
its appeal.

But note that the dates do not have to fit any one
particular XML schema. For default mark up generation,
the values need only conform to the date requirements
for ASN.1 values given in X.680. 

What is critical to understand here is that ASN.1
provides a stable schema for values and structure
of data, and that XML mark up can be used to convey
ASN.1 specified values.

I anticipate that after the work is completed on 
default XML tagging, that a facility will be provided
that allows the default ASN.1 generated XML mark up 
to be completely controlled by the user. It seems
that the ECN work has demonstrated that this type
of capability can be provided through a notation
carried in separate files associated with an ASN.1
specification.

This should provide enough flexibility for tools to 
generate whatever format the user desires, including 
partially tagged data, HTML, HTML, XML, XML with DTD,
XML with XML-schema, XML with RELAX, XML with DT4DTD, 
etc. 

With any luck, users should also be able to generate 
plain text encodings and ASN.1 value notation.

Phil