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] Rewriten SimpleSign page


Hi Nat -

Thanks for writing that up.  I've got a few comments:

1) The core XRD use cases do not require XRDS documents.  Shouldn't we
defer specification/handling of XRDS to the XRI spec?  I don't feel
particularly strongly on this, just seems like a way to simplify.
What are the XRD applications that need XRDS?

2) The canonical ID == subjectAltName rule is not going to work for
most applications, for multiple reasons:
    a) you can't buy those certs.
    b) even if such certs did exist, they would make key rotation and
reassignment impossible.
    c) even if such certs did exist, the proposal would require
purchasing a separate certificate for every single user of a site.

Those are three deal-breaking obstacles to deployment.  I can't
imagine anyone ever deploying that scenario on the open web.  It might
get deployed in some more controlled/restricted environments, though
the complexity of the model will be a problem even there.

If there is consensus in the TC that we need both a canonicalID ==
subjectAltName rule (section 3.2.1) and a DNS name rule (section
3.2.2), let's handle it by defining separate trust profiles
(http://wiki.oasis-open.org/xri/XrdOne/TrustProfiles).  That way we
can keep most of the security steps identical across deployments and
code, with limited differences called out clearly.

The DNS name rule you've described is pretty close to the HTTP
authority trust profile I wrote up earlier
(http://wiki.oasis-open.org/xri/XrdOne/TrustProfileHttpAuthority).
The canonicalID == subjectAltName rule would be a "cert per document"
trust profile.

3) I have a preference for reusing the XML DSIG schema where we are
redefining elements that have the exact same semantics.  For example,
your XRD/Cert element has exactly the same semantics as
ds:X509Certificate, but you've used slightly different syntax.  Rather
than creating new syntax, we should just pull in the definitions we
want from XML DSIG.  We won't be able to reuse much code, but we'll be
able to reuse the thought they put into their definitions.

Cheers,
Brian

On Thu, Dec 18, 2008 at 10:47 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
> I have re-written the XrdOne/SimpleSign page to reflect the talks today.
>
> http://wiki.oasis-open.org/xri/XrdOne/SimpleSign
>
> Hope this is simple enough and close to an agreement.
>
> I have changed <SXRD> element name to <SDSIG> to generalize it.
> Perhaps that's too much of a generalization though.
> Also, instead of ds:KeyInfo, I have flattened things and defined
> <CertURI>, <Certs>, <SigAlg>.
>
> We do not gain much by borrowing just ds:KeyInfo from XML Dsig.
> If we have XML Dsig processor, we would be using XML Dsig after all.
>
> =nat
>
> ---------------------------------------------------------------------
> 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]