Re: [xri] [Libraries] Response to >> Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-12-17

Nika, that's great, we'll look forward to it.

Do take time for the holidays while you're at it ;-)

Best,

=Drummond

On Thu, Dec 17, 2009 at 5:06 PM, Nika Jones <> wrote:

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

>

>

---------------------------------------------------------------------

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