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] 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 <breno@google.com> 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 <breno@google.com> wrote:
> Thanks, Will!
>
> On Thu, Jan 21, 2010 at 11:17, Will Norris <will@willnorris.com> 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




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