RE: XACML OID tag?

[Peter Williams <peterw@xxxxxxxxxxxx>]

If one profiled X.509 to change the OCTET
STRING of the extension type to be OCTET STRING 
(CONTAINING UTF8String ENCODED BY xml), then this
would seem to meet the profiling rules, for
the xml environment.

Sharon would have to alter X.509 to remove
the comment on extnValue that requires
DER encoding of a (ASN.1) type. Her change
could indicate that the encoding should DER
unless profilers specify an CONTAINING
and ENCODED BY to specify different rules.
Obviously, the extnID can implicitely communicate the
contents and encoding rule, when the defaults are
not to be assumed.

IT seems strange now to force a particular
canonicalization scheme, given we have
others now, more fitting the usage
environment of (encoded) ASN.1 values.

If we do this, we can avoid specifying
extensions which bear an "OCTET STRING ASN.1
type" (which then bear the xml-encoded
utf8), merely to satisfy the comment
in the standard.

-----Original Message-----
From: Phil Griffin [mailto:phil.griffin@xxxxxxxxx]
Sent: Tuesday, September 11, 2001 3:02 PM
To: Rich Salz
Cc: Bob Jueneman; ietf-pkix@xxxxxxx
Subject: Re: XACML OID tag?



Rich,

CXER can be related to signing canonical XML
encodings of ASN.1 values. It has not been
targeted at all to the workings of XMLDSIG.

But a canonical encoding of an ASN.1 value
can be carried easily in an ASN.1 value, say
an attribute or extension using

Payload ::= 
   OCTET STRING (CONTAINING UTF8String 
                    ENCODED BY xml)

where "xml" is an object identifier. There are
many other useful variants that can be processed
by XML-aware ASN.1 tools.

Phil Griffin



Rich Salz wrote:
> 
> How does CXER relate to the the XML Canoinicalization spec, designed as
> part of XML DSIG?
> 
> I hope the answer is "the same," but I doubt it. :(
>         /r$
> 
> --
> Zolera Systems, Your Key to Online Integrity
> Securing Web services: XML, SOAP, Dig-sig, Encryption
> http://www.zolera.com