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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04


Scott,

Thanks much for the clarifications. The next step is for Will to write this
up in the next Working Draft. I'm sure he could use your help in getting the
spec text right about these points.

Will, you'll probably save yourself time by having Scott review your next
Working Draft early.

=Drummond 

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Saturday, June 06, 2009 9:27 AM
> To: 'XRI TC'
> Subject: RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04
> 
> Drummond Reed wrote on 2009-06-05:
> > Following are the minutes of unofficial telecon of the XRI TC at:
> 
> Some clarifications inline (not corrections to the minutes, just the
> statements made in them).
> 
> > Drummond asked for clarification on whether the signature MAY be
> > referenced rather than enveloped. It was still unclear whether the
> > constrained XML dSig profile allows this or not - what we are sure of is
> > that it supports enveloped signatures.
> 
> It doesn't preclude it, but it isn't formally addressed by a profile
> describing constraints on enveloped signatures. A detached signature would
> need to be described separately, but is supported by XML Signature itself.
> 
> > (Dirk made the point that adding
> > an element to XML dSig should not break it because the added element
> > should be able to be excluded.)
> 
> I'm not sure what that refers to, but adding elements to the XML Signature
> schema is only permitted in a few places where wildcards were defined. You
> can't do anyting that violates the schema.
> 
> > Will explained this this profile references a W3C spec for "exclusive
> XML
> > canonicalization" adds a few additional constraints, most notably a
> strong
> > recommendation against using Q-names.
> 
> That isn't a constraint of excl c14n, it's a best practice in order to
> maximize interoperability when you use it. With excl c14n, you don't
> output
> a namespace prefix decl until/unless it gets "used" by an element or
> attribute. With QNames in content, you don't know that the prefix is being
> used because the c14n algorithm is unaware of QNames in content. The fix
> is
> to include the prefix in the InclusivePrefixes parameter to the algorithm,
> but knowing to include the prefix in that list when signing requires
> application intervention.
> 
> The support for InclusivePrefixes is trivial to implement in the
> signing/verifying layer. It doesn't make the work harder. The cost comes
> in
> the outer layer that's handling the thing being signed.
> 
> > Will explained that normal XML dSig
> > canonicalization inherits from parent elements. Exclusive does not do
> that,
> > and does not require XPath referencing, because all you can reference is
> a
> > single element by its ID attribute.
> 
> That's also coming not from c14n itself but the profile. You avoid XPath
> by
> limiting what you can sign and place in the Reference URI, and by limiting
> the Transforms allowed so that you don't have to support XPath at all
> unless
> you choose to implement more than the profile requires.
> 
> > Brian suggested that we have either use an existing set of XML dSig
> > libraries for testing or develop our own. There was strong consensus
> that
> > this is essential.
> 
> As I said, there are test vectors from W3C that should work, or we can
> generate some easily enough.
> 
> -- Scott
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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