Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-12-17

[Will Norris <will@willnorris.com>]

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.