Re: [xri] Re: Proposal for an X.509-based XRI Trust Profile

Breno, I don't have strong feelings about the three options for #1 below, but given how you describe them, I lean toward 1c. The reason is that, as you describe it, you are either validating all three legs or just two legs. That means you could compose the spec in the following way:

1) Here's how you do two legs,

2) Here's one known way to do the third leg

3) If you want to specify an alternative way to do the third leg, here are the requirements for that specification.

That seems conceptually like a clean way to do it and to let others like LRDD extend it. But take all that with a appropriate spoonfuls of salt because I only play a security guy on TV (if you've seen "Chuck", that's me ;-)

=Drummond

On Thu, Jan 21, 2010 at 3:19 PM, Breno de Medeiros <> wrote:

Okay, summarizing the two points I raised in the discussion today

about the XRI spec.

1. Give guidance on how extensions can adapt the profile to use other

trust anchor elements in the document (such as <hm:Host>) instead of

<subject> and <alias>

or:

1b. Do nothing and remove reference to host-meta. Then let LRDD trust

profile define how to validate a Host-meta using an 'XRD-trust-lite'

validation + matching on <hm:Host>

or:

1c. Make the 'authority name' or 'claimed subject' input optional and

define two types of validation:  validation without a claimed subject

'XRD-trust-lite', putting stern language that applications using this

profile should only use an empty 'claimed subject' if they have other

means to bind the XRD to the resource they intended to find meta-data

about (e.g., via alternative elements of the XRD defined through

extensions).

And

2. Allow root certificates to equal the signer certificate, in which

case the certificate matching step is not performed. I think this does

not add too much complexity to the spec.

On Thu, Jan 21, 2010 at 11:22, Breno de Medeiros <> wrote:

> Thanks, Will!

>

> On Thu, Jan 21, 2010 at 11:17, Will Norris <> wrote:

>> Here's a straight formatting of the draft using docbook + the OASIS xslt stylesheet.  If there are any deviations from the plaintext draft Breno sent to the list, they are not intentional.  I'm fairly sure there are a few "must"s that are intended to be normative, but for now I left everything alone.

>>

>> I haven't checked this into subversion just yet because I'm not sure how we want to structure this.  We can talk about it on the call today.

>>

>> -will

>>

>>

>> ---------------------------------------------------------------------

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

>

--

--Breno

+1 (650) 214-1007 desk

+1 (408) 212-0135 (Grand Central)

MTV-41-3 : 383-A

PST (GMT-8) / PDT(GMT-7)

---------------------------------------------------------------------

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