[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: asn1xml Re: PKIXML session. Was: PKIX WG tentative agenda
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:phil.griffin@asn-1.com]
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:aram@pacbell.net]
> > 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 asn1xml@oss.com, 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