XML interface with URIs

All,

	So far there seems to be general agreement that the
XML-Sig work should broadly correspond with CMS functionality
without requiring ASN.1 at the packaging level.

	I don't think there is (or will be) consensus to delve
any deeper into the encryption layer, such as respecifying 
PKCS#1 or such.


	If this is the basis for going forward I would like
people to consider that what makes XML interesting is not
the SGML inheritance. In my view what is interesting about
XML is that it takes advantages of URIs to establish naming
and locators.

	I see a number of interesting applications of URIs which
can provide CMS/PKCS#7 functionality in an manner that is
compatible with XML infrastructure. I will first list these
proposals then give applications within XML

	Note that these are all 'genuine URNs' - ie URNs as they 
were originally defined. They do *not* have location functions,
nor is their purpose to provide a locator. They do not in general
satisfy the "requirements" for URNs document of the IETF. I don't
consider that a shortcomming.


FN:<alg>/value
	This name binds to a particular sequence of bytes. The
value segment of the digest is the Base32 representation of
the digest value of the referent under the specified algorithm
with trailing = signs omitted.

	Example	FN:SHA/2A9E93JFD03JWODS934JFIWQ33	

OID:<number>/<value>
	This name represents an ASN.1 OID / attribute pair. The
usage is to import semantic tokens defined in PKCS#7/CMS space
into XML space. The value is the attribute value Base64 encoded.

	[Folks who really, really don't like ASN.1 could use
this OID to decant the entire PKIX semantics into Signed XML
space]


Rationale:
	Why use Base64 and Base32 - try reading out Base64 on a
telephone line. I believe that Base32 is a better encoding for
keying material which may need to be communicated out of band.


Usage of FN:

	The FN URI allows a signed XML document to incorporate
transcluded elements into the scope of the signature without
necessarilly requiring a compound document to be created.

	So an <a href="http://somewhere.org" 
urn="FN:SHA/29DCN20FJW20FDSJ25TJUAS0">included document</a>
can be incorporated into the signature scope.


Usage of OID:

	The OID incorporates signing semantics defined in an ASN.1
specification into XML space. So a group of business partners may
already have agreed that the OID 1.56.2.5.2 stands for "terms of
trade" and incorporate it into their signatures:

<SIGNATURE value="2097FJQW098WFJQ23098GW3E09U=="
attr="OID:1.56.2.5.2/2309FJ2jf039hfaw09wungt0"
attr="OID:3.2.5.12.12.22/AA03j2j5==">


		Phill

Received on Monday, 26 April 1999 10:34:05 UTC