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] Trusted Rev Draft

Thanks Gabe. Great feedback. I'll try to have a new draft by the end of the
week incorporating your comments, then respond to this mail item by item if
it seems useful.


> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Monday, March 15, 2004 11:22 AM
> To: 'Dave McAlpin'; xri@lists.oasis-open.org
> Subject: RE: [xri] Trusted Rev Draft
> Dave-
> 	Feedback follows. I'm very happy with this document in general.
> * Would it be useful (or neccesary) to talk about how secure resolution
> might affect the operating relationships between authorities, and
> specifically talk about deployment and what sort of coordination is
> required? What impacts are there for deploying secure resolution data
> above and beyond normal resolution data. For example, not only do
> authorities have to get "pointed at", they also have to submit their
> AuthorityID's to their "upstream" authority.
> * To make processing easier, I've defined the content model of the
> XRIDescriptor (and its children) to allow any elements *after* the defined
> elements. That is, if you are going to insert new elements (in this case,
> the xrit: elements), they must appear after all the elements defined in
> the base XRIDescriptor namespace. So, for example in your first example
> (the examples don't have captions - they should!), the ds:KeyInfo element
> which is the immediate child of the XRIDescriptor should come after the
> last element defined by the XRI Syntax and Resolution spec - in this
> example, the ds:KeyInfo should come *after* LocalAccess element in this
> example. The idea is make it easy for "dumb" processors to detect
> extension elements and be able to say "OK, I'm done, I can ignore
> everything else".
> * Captions and figure/example numbers should be included so we can refer
> to them ;-)
> * Shouldn't we talk about signature validity conditions? Specifically
> about how long the signature of a resolution result can be trusted? Keys
> themselves have a lifetime, typically, so that provides an "outer bounds"
> for signature validity lifetime, but shouldn't there be a way to constrict
> this span much more? In other words, express that a signature should only
> be trusted for a limited period of time?
> 98-99: The tone and/or voice here should be a little more formal. For
> example,  "Before we look..." doesn't fit with the rest of the spec.
> 133: "Confidently" - while I know what you mean, need to use a more
> descriptive phrase - perhaps "Associating an IP address with a domain name
> in a trusted and secure manner..."
> 148: Typo - "@exmple." should be "@example."
> 212-233 See bullet "GENERAL" comment about extension elements appearing
> after "core" elements
> 291-215 This example omits the ds:KeyInfo element.. If I'm interpreting
> this correctly, it is legal to do this, but it implies that there are no
> further authorities beyond =example.home.base Perhaps some verbiage saying
> just this would be useful, so the absence of ds:KeyInfo is better
> understood and by implication, the purpose of ds:KeyInfo is highlighted.
> 357: Yes, a simple schematron would be useful. Put that down as an action
> item for Gabe.
> 358: Yes, definitely need to talk about the interaction with redirects.
> Feel free to impose further restrictions on HTTP redirects as well.
> 383-384: Talking about failure to verify a resolution step - what about
> the ability or advisability of a client to try and alternate resolution
> step. For example, if two URIs are listed under and XRIAuthority element,
> and one fails to do "xritrusted=true", do we suggest that a client is free
> to try the other URI? What if the next authority gives back a signed
> authority, but the signature validation fails? Should there be language
> making this "alternate" behavior ALLOWABLE, REQUIRED, or SUGGESTED?
> 386: Yes, schematron++ - put it down on my todo
> 387-388: YES, should discuss HTTP redirects and how it interacts with the
> security mechanism.
> 407-412: Not completely sure, but I think KeyInfo should NOT be optional.
> The fewer implied or unspecified sources for data the better (from an
> interop POV), usually. Are there good reasons in our context to allow
> omission of KeyInfo? What is the DigSig spec addressing with this?
> 416: "the value that will appear in the xrit:AuthorityID element of an XRI
> Descriptor retuen dfrom the described XRI Authority" - in this context, I
> get confused about the term "described XRI Authority".. What exactly are
> we referring to?
> 459: I think the Security Considerations is very important here. This is a
> "trusted resolution" specification after all ;-)
>     -Gabe
> -----Original Message-----
> From: Dave McAlpin [mailto:dave.mcalpin@epok.net]
> Sent: Friday, March 12, 2004 3:21 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Trusted Rev Draft
> I just posted a first draft of the trusted resolution spec. It's got quite
> a
> few comments and TODOs, but I think it's complete enough to evaluate.
> Feedback is very much appreciated.
> Dave
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to http://www.oasis-
> open.org/apps/org/workgroup/xri/members/leave_workgroup.php.

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