Subject: RE: XACML OID tag?

From: Peter Williams <[email-masked]>
Date: Tue, 11 Sep 2001 16:51:38 -0700

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:[email-masked]]
Sent: Tuesday, September 11, 2001 3:02 PM
To: Rich Salz
Cc: Bob Jueneman; [email-masked]
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

---

From: Phil Griffin <[email-masked]>
Date: Wed, 12 Sep 2001 01:54:44 -0400

Peter,

> contents and encoding rule, when the defaults are

Well, the OCTET STRING here could follow the current
rules, as could the value of it's content, a UTF8String.
But the UTF8String here would carry an XML markup payload.

But I was actually looking one level deeper when I wrote
this. That is, I was looking at this OCTET STRING as a
possible payload (in an Extension case at least) within
the extnID. So that would be an OCTET STRING that 
contained "Payload" which contained a UTF8String that
carried XML markup. 

Of course, there are other cases in ASN.1 messages where
such nesting would not be required. 

> utf8), merely to satisfy the comment

Yes, ASN.1 values already have canonical encodings;
the commonly used DER, the unused (I think) CER,
a canonical PER variant, and soon CXER, a canonical
encoding variant of the XML Encoding Rules of ASN.1.

Phil