Re: XACML OID tag?

[Phil Griffin <phil.griffin@xxxxxxxxx>]

Peter,

Peter Williams wrote:
> 
> 
> 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.

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. 

> 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.

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
 
> -----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