[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]