[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Libraries] Response to >> Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-12-17
In response to Libraries... I will update the PHP one I have this weekend and give out the URL early next week. Nika > Following are the minutes of the unofficial telecon of the XRI TC at: > > > Date: Thursday, 17 December 2009 USA > Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC) > > ATTENDING > > Will Norris > Tatsuki Sakushima > Breno de Medeiros > RL "Bob" Morgan > Scott Cantor > > > 1) DISCUSS REVISIONS TO XRD COMMITTEE DRAFT 01 REVISION 01 > > Will asked if there was any additional feedback on the Public Review wiki > page... any responses that needed work, or any feedback that we missed > including? > > http://wiki.oasis-open.org/xri/XrdOne/PublicReviewFeedback > > Breno noted that there was considerable discussion on the OpenID mailing > list, particular around the <Subject> element, but agreed that what we > have on the wiki encompassed all of the major points from that discussion. > > > 2) TRUST PROFILES > > Breno mentioned that he has been working on drafting a trust profile for > XRD and/or LRDD using X.509 certificates. One of the particular > challenges was whether this should be one document or multiple, and what > the scope of each should be. A document that only defines a trust profile > for generic XRD documents doesn't cover the Host Meta use case, because > Host Meta has no <Subject>. Similarly, including Host Meta in a somewhat > generic trust profile seems odd since it's not part of the core XRD spec. > > Will noted that he had always imagined that there would be at least two > documents... one that defines what to do with generic XRDs, and then > another for Host Meta that references the first, but explains what to do > about <Subject>. > > (We then had a lengthy discussion about the approaches to XRD trust, > mainly between Breno and Scott. There are a few holes, but I think I > captured most of it:) > > > Scott: so you want to use TLS name matching rules for something that isn't > TLS (which is fine). If you want to do this, then you need to be very > precise -- specify the OID you want, and where in the cert is should > appear. My suggestion is, unless you have a strong argument for doing it, > you try and not rely on certificate extensions. The SAML example is quite > illustrative -- there is no extension that means you are allowed to sign > SAML assertions. Different people will interpret the application of > extensions differently. > > Scott: If you try to interpret the certificate semantically, I guarantee > you will have interop problems. The answer is that if you rely on > commercial CA's, you're effectively misusing what those CA were designed > to use. If you take something intended for SSL (which is what CA's > issue), those certs do not mean what you want them to mean (valid for > signing XRD documents). The CAs were not issuing the certs, and binding > them to the names they bound them to, for the purposing you're describing. > > Breno: But CAs typically do not allow you to add arbitrary extensions. > > Scott: if you're trying to use the SSL infrastructure for your trust > model, you should not sign the XRDs. If you're relying on SSL, then > actually rely on SSL. I should host my XRD at a secure URL that can be > plausibly bound to the subject. Anything else is a misuse of SSL > certificates. When we use them in SAML, I'm okay with it because we have > metadata that specifically says what they are intended to be used for. I > personally would be somewhat uncomfortable with the idea that I should > trust a signature that was signed by a TLS certificate. But to the extent > that you do that, if you're going to use any extension at all, it would be > the TLS server extension, which is a signing extension. > > Breno: what I've heard (but unable to confirm) is that some CAs will issue > certificates with additional extensions that can be used both for TLS and > for code signing. I've not seen one of these yet. But I would imagine > that if such a certificate were issued, it would not be stretch to use the > TLS name matching to verify the authority. > > Scott: It depends on what thread model you're trying to protect against > (not using TLS loses the man in the middle protection). > > Scott: It's a slippery slope to try to define matching rules and extension > requirements, if you stop there, but then try to leave the rest of the > evaluation process undefined or loosely defined. The reason I'm trying to > abondone the use of PKI, is that no one wants to be precise in how to > validate the certificate (do I use CRL, OCSP, what extensions, etc). > Everyone just punts and says "it's up to the relying party" which doesn't > help me as an implementor. > > Breno: there is still value in providing an interop layer. Now we could > just say PKI is complicated, there are all these issues (which there are). > But I don't know much of an alternative that would be simpler > > Scott: well there is a simpler requirement, but it doesn't meet the > requirement of dynamic bootstrapping. We (SAML) exchange trust data out > of band. > > Breno: in practice you can get a long way with the dynamic bootstrapping > of TLS > > Scott: but TLS just doesn't work. browser security today is useless except > in the EV case. One of the reasons for that is because CAs do not vet > identity within organizations. They only vet organizational identity. > > Scott: If you're going to write up a profile that uses PKI as the basis > for its trust, I would argue for specificity. If you don't and leave it > undefined or loosely defined, then I have no idea what to actually > implement. I know that every library is buggy in different ways, and I > don't know which bugs I should care about. Which is an interop mess. I > would suggest we be as specific as possible with all the pieces that are > mandatory for people to do. Either was specifically say we ARE or ARE NOT > expecting use of CRLs, etc. That is what has led me to give up and just > go in the other direction [with SAML]. > > Scott: Everybody is doing this stuff with PKI, and the rest of us are > avoiding it, because they are not being specific in what they mean by > "PKI". Now I just do what OpenSSL does, and point to them when there are > bugs. But meanwhile we're doing this other model where we DO control > everything and know exactly what will work. > > Scott: In my experience, when your security requirements are low, they're > usually zero. I've not found any evidence that even a low security model > is leading to any better security overall. > > (some discussion of DNS Sec that I missed) > > Breno: while you could certainly use self-signed certs and bring trust in > from somewhere else. But we also thought that using TLS provides some > non-zero value. > > Scott: what is the advantage of having the XRD signed using TLS, rather > than just using a protected endpoint to retrieve the XRD? > > Breno: XRD libraries will have less control over validating the trust of > the XRD, because the transport layer will be handling TLS. It's much more > difficult to maintain that trust information throughout the process. > > Scott: If you're going to do a profile on the side of simplicity, if > you're not going to go to such extents that you're likely to avoid all the > PKI validation pitfalls.. I actually wouldn't go too far down the road of > extensions. > > Breno: If you're going to be using TLS name matching, there is no point in > requiring anything beyond a standard TLS certificate. If we clarify the > levels of assurance we're hoping to get with this profile (not incredibly > high, but something comparable with browser security), and what the goals > are, we can simplify this considerably. > > Scott: the other issue is that it's difficult to write a completely > generic trust profile. the threat models are specific to the use cases. > the best thing to do is to be as limited as possible in the base profile, > and let others lock it down for their specific use cases. > > > 3) TESTING LIBRARIES > > Scott asked whether there were many libraries being written right now for > this, and if any attempt had been made to do any interop testing. Tatsuki > mentioned he had a new XML canonicalization library in pure ruby, and Will > noted that there was talk of a perl library on the webfinger list, though > it was not clear if they were going to support signing. > > AI: Scott is going to gather existing XML canonicalization test cases so > that we can test interop with the current and upcoming libraries > > > 3) NEXT CALL > > We will be taking a break over the holidays, so the next call will be > Thursday, January 7, 2010. > > > --------------------------------------------------------------------- > 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]