[WG-OTTO] 8/26 OTTO Meeting Agenda / Reminder

Keith Hazelton keith.hazelton at wisc.edu
Wed Aug 26 09:49:59 CDT 2015


Comment and question on one of the points in Nate’s dogma:

"Rather than trying to solve the distributed signature problem, I
want the replacement for metadata to include pointers to attesting
authorities. A provider could proceed to query a mutually trusted
authority to verify the good standing of a recipient. This also allows a
single entity to point to multiple authorities, something that is a
challenge with signatures over files. I also don't have to magically
know your trusted authorities: you tell me who they are. Mutual TLS
authentication to both the recipient and the authority gives
cryptographic security to this chain of relays. This is a
provider-centric alternative to the federation-centric being pursued
today."

COMMENT: But traditional CA model has been proven untrustworthy. 

The biz value of 3rd party trust assertions is that a participating party evaluates the trustworthiness of the 3rd party once. The 3rd party shows what and how it validates other parties. If the participating party is satisfied with that, they can trust any/all of the parties certified by the 3rd party without themselves having to evaluate each one. Without that, the repeated evaluation/vetting process is a significant resource sink.

How do proposed alternatives achieve that savings?
-- 
email & jabber: keith.hazelton at wisc.edu
calendar: http://go.wisc.edu/i6zxx0








On 2015-08-25, 22:30 , "wg-otto-bounces at kantarainitiative.org on behalf of Mike Schwartz" <wg-otto-bounces at kantarainitiative.org on behalf of mike at gluu.org> wrote:

>
>This is probably too ambitious... but:
>
>1) Approval of minutes / reminder about nominations.
>
>2) Discussion of Section 2 and 3 of Nate's dogma. Breaking this down 
>into the following discussion points: (Note, we'll have to take the 
>other sections later, as I don't think we'll get through this in one 
>meeting). If you haven't read it, don't worry. We're going to discuss it 
>point by point anyway. But I am attaching the doc.
>
>Points to discuss:
>    - "Attribute requirements are notoriously difficult to express, 
>making out of band communication necessary anyway"
>    - "Dynamic metadata has been difficult to get done, and that’s 
>because we’re trying to build DNSSEC + IPsec rather than TLS... Every 
>entity name must be a URL that is resolveable into a description of the 
>entity and how to talk with it."
>    - "The content of metadata needs to be replaced or amended to be both 
>more informative(provisioning, attribute, and consent stuff) and less 
>informative(deprecate lightly used data fields). It also needs the right 
>primary index(probably domain, because that’s the more common bootstrap 
>for discovery) and secondary indices."
>    - "Rather than trying to solve the distributed signature problem, I 
>want the replacement for metadata to include pointers to attesting 
>authorities. A provider could proceed to query a mutually trusted 
>authority to verify the good standing of a recipient. This also allows a 
>single entity to point to multiple authorities, something that is a 
>challenge with signatures over files. I also don't have to magically 
>know your trusted authorities: you tell me who they are. Mutual TLS 
>authentication to both the recipient and the authority gives 
>cryptographic security to this chain of relays. This is a 
>provider-centric alternative to the federation-centric being pursued 
>today."
>   - "Distributed signature is one of the most challenging problems I 
>know of. Do you hand out keys with no control over file contents? Do you 
>sign files and give them to people, basically reproducing the CA model 
>at a second layer? I’m not convinced it even offers a superior solution. 
>Pointers and queries are vastly easier in practice. They don't fix the 
>problem, as the authority in the response still has to be
>meaningful to the asker, but it does add the ability to build chains of 
>authority and removes the need for a single MDA to act as an oracle."
>   - "Rekeying with your key scattered all over the place is brutally 
>painful. Federations are supposed to alleviate this, but wouldn't 
>distributed rekeying be alleviated by just querying the server and then 
>validating the credentials?"
>   - "Being able to definitively say that an entity doesn’t exist is 
>effectively impossible, while reconciliation of different answers from 
>different authorities is effectively unspecified."
>   - "Most large SP’s that are in heavy use by academia (Office 365, 
>Google Apps, and Box being the elephants in the room) do discovery by 
>domain, and so almost definitionally can’t use our metadata approach for 
>perhaps the most important function."
>   - "Metadata gives no cues about why attributes are requested, why 
>they’re needed in terms both administrators and consent users could 
>interpret, what would happen if they are not received, what provisioning 
>requirements exist, and basically everything else I had to write into 
>the service-specific guidances for NET+."
>   - "We have to agree on authorities that we trust out of band. There is 
>no way to discover from an entity which authorities vouch for it. This 
>constraint has led to everything getting herded into one gigantic 
>aggregation service where we there are trust and compatibility issues."
>   - "I have to ensure that all my metadata everywhere is the same. This 
>means I either force all my partners through a single federation, or I 
>have to keep all representations of me consistent, or I risk incoherent 
>provider behavior. Allowing multiple directly expressed relationships 
>relieves these restraints somewhat, and it allows a provider to seek 
>simply a connection that meets attribute and trust requirements rather 
>than ensuring that all metadata everywhere is the same."
>  - ""
>
>3) If George is able to join us this may get moved to #2 because I don't 
>think its a long discussion. If not, we'll keep moving it to the next 
>meeting.
>OpenID Connect Thread on "claims" in the Client Registration Spec:
>   
>http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150810/005680.html
>
>
>
>-------------------------------------------------------------------------------------
>
>Meeting Details - NOTE: Don't use the G2M audio... see bridge details!
>
>-------------------------------------------------------------------------------------
>
>Screen Sharing: https://global.gotomeeting.com/join/162399285
>
>Audio: Skype: +99051000000481
>North America Toll: +1 (805) 309-2350
>Alternate Toll: +1 (714) 551-9842
>International Toll: http://www.turbobridge.com/international.html
>
>Conference ID: 613-2898
>
>Command Menu: 0 Plays menu of Keypad Commands *3 Promote to Host (if 
>non-host) *5 Raise your hand *6 Mute yourself
>(toggle on/off) *# Private roll call of participants *\ Mute 
>music-on-hold (toggle on/off)
>
>TurboPhone (beta): https://www.turbobridge.com/join.html Works with 
>Internet Explorer on Windows only
>
>SIP Access (using IP phone or soft phone) sip:bridge at turbobridge.com
>SIP URL details: https://www.turbobridge.com/help/Index.html?context=180


More information about the WG-OTTO mailing list