OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Schema-centric C14N for SAML. Forwarded message from Scott Cantor.


More on canonicalization for our XACML XML DSig Profile...

Anne
------- start of forwarded message -------
From: Scott Cantor <cantor.2@osu.edu>
To: Anne.Anderson@sun.com
Subject: RE: Schema-centric C14N for SAML
Date: Thu, 04 Sep 2003 12:26:04 -0400

> The SAML C14N guidelines do not handle canonicalization of 
> primitive data types (e.g. Boolean represented as 
> "true/false" or "1/0"), default values of attributes and 
> element content, etc. These seem to be so basic that they 
> should be addressed by SAML and not separately by each payload.

Well, you're trying to work at the logical infoset level and thinking about
signing data as typed information, whereas XML and XML Signature don't. It's
not obvious that every XML specification should take on that responsibility,
to me. That's a lot of duplicate work.

> Joe Reagle suggested I look at Schema Centric XML Canonicalization 
> (http://uddi.org/pubs/SchemaCentricCanonicalization.htm).  
> This seems to do what is needed, and also 
> addresses lots of other C14N considerations that seem very 
> important although my XML/C14N expertise is insufficient to 
> understand them fully.

Yes, my personal opinion is that the xmlsig WG made a mistake by punting on
schema. The outcome of that decision is that signatures and XML Schema
validation or data normalization don't play well together. But I seem to be
in a small minority of validators, so I think most people just ignore the
problem. That works for some of the technical issues, but it doesn't solve
your problem with logical data normalization.

The problem is that because the spec only really "blesses" Inclusive and
Exclusive C14N, nobody widely implements anything else. I'm not aware of any
actual implementations of this proposal, for example, though I imagine there
might be some.

This has come up a lot in SOAP, since 1.2 now defines itself only in terms
infoset, and so signing and verifying SOAP becomes hard to pin down. Rich
Salz proposed a SOAP C14N too.

> Are there plans to take the SAML Guidelines a step further?

Well, I suspect it's worth some discussion, but the usual criteria when
discussing signature profiles is "what's widely implementable?"

It might be worth adding some minimal specification language like SOAP does
to cover things like booleans, but I have a suspicion that that's a
difficult thing to address comprehensively.

> Has anyone looked at SC XML C14N?

I did, when I started to understand the problems with signatures and schema
validation. The problem is, you have to not only implement the algorithm,
but then plug it into every signature library you plan to use, none of which
have any uniform way of doing so, if they even have a way to add custom c14n
algorithms.

-- Scott
------- end of forwarded message -------

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]