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: Posting on XRD Signatures (was RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04)


I agree that it would be good to advise these two communities of what we're
planning. I had dinner the other night with David Recordon and Joesph Smarr
and previewed this with them and they were fine with it.

Who is going to do the post to the OpenID General and OAuth lists?

=Drummond 

> -----Original Message-----
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> Sent: Monday, June 08, 2009 5:42 PM
> To: Breno de Medeiros; Drummond Reed
> Cc: Scott Cantor; XRI TC
> Subject: Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04
> 
> Good idea.
> 
> Let us do it on OpenID General and OAuth list at least.
> 
> =nat
> 
> --------------------------------------------------
> From: "Breno de Medeiros" <breno@google.com>
> Sent: Tuesday, June 09, 2009 7:46 AM
> To: "Drummond Reed" <drummond.reed@cordance.net>
> Cc: "Scott Cantor" <cantor.2@osu.edu>; "XRI TC" <xri@lists.oasis-open.org>
> Subject: Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04
> 
> > Should we circulate these minutes in the openid general mailing list? As
> a
> > source of general feedback?
> >
> > On Sat, Jun 6, 2009 at 12:27 PM, Drummond Reed
> > <drummond.reed@cordance.net<mailto:drummond.reed@cordance.net>> wrote:
> > 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<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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
> >
> > --
> > --Breno
> >
> > +1 (650) 214-1007 desk
> > +1 (408) 212-0135 (Grand Central)
> > MTV-41-3 : 383-A
> > PST (GMT-8) / PDT(GMT-7)
> >



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