[Pgi-wg] Sec: Agreement on SOAP and authentication

[Duane Merrill]

I don't understand the strict "either-or" wording below with regards to PCs
versus PKCs in a *proxy-plus-embedded-AC* conformance target.  You make it
sound like their use would be unilaterally mutually exclusive.  Both types
of certificates can embed attribute certificates, and there is an
"is-a"/polymorphic relationship here: a PKC is a PC of delegation depth zero
(and therefore does not have the extension OID set).

A *proxy-plus-embedded-AC* conformance target should describe
implementations that allow both.  In the strawman document, the goal of
layering the *pgi-tls-proxy* conformance target on top of the
*pgi-https*target was to add functionality (not take it away):
*pgi-tls-proxy* describes SOAP implementations that perform mutual SSL/TLS
authentication with certificates, and these certificates MAY have proxy
extensions (making them PCs) and MAY have AC extensions (embedding attribute
certificates).

Perhaps I am just misinterpreting your language.

-Duane

2009/3/19 Morris Riedel <m.riedel at fz-juelich.de>

> Hi security folks,
>
>
>  reading certain elements of the IIRM, strawman, and following discussions
> on the list - I see there is still no common agreement on SOAP / HTTP(S) in
> some areas.
>
> ### Goal:
>
> (a)
> We are discussing if SOAP / HTTPS can be used in PGI to contact a
> functional
> interface (like BES)...
>
> (b)
> ...because we want to find out if there is any important service in the PGI
> context that is not capable of using SOAP (over SSL layer)...
>
>
> (c)
> ... in order to find out if we can agree on SOAP/HTTPS or to understand
> requirements from other non WS-based interfaces in PGI.
>
>
> Therefore the aim of this thread is to get to an agreement in this context,
> while considering Attribute authorities like VOMS as a supportive service
> and not an functional interface (also separate thread).
>
> ### Contacting functional implementations with SOAP
>
> If we consider the case that we communicate with an functional interface
> like OGSA-BES - we agree on SOAP.
>
> ### TLS/SSL Layer:
>
> # <strawman>
> Foundational: Conveying identity for authentication.
> SOAP over HTTPS (PGI_HTTPS).  SOAP-over-HTTP communication using a SSL/TLS
> transport protocol in which endpoints are mutually authenticated by X.509
> end-entity public key certificates (PKCs).
> # </strawman>
>
>
> # <simple plumbings: authentication>
> We use authentication either based on identities inside X.509 end-entity
> public key certificates or X.509 proxies (including restrictions, encoding
> handled separately in another thread).
>
> This refers of using either one or the other of these certificate types on
> the SSL/TLS level.
>
> For simplification of the profile - there should be no direct dependencies
> with attribute-transport used for authorization.
> # </plumbings>
>
>
> ### Possible scenarios:
>
> # A. TLS with end-entity certificate, SOAP in message -> authN check with
> CA
>
> # B. TLS with (restricted) proxy certificates, SOAP in message -> authN
> check with proxy signer chain
>
> ### Possible Conclusion:
>
> # We use SOAP inside a message to contact functional interfaces.
>
> # We use either full X.509 end-entity certificates OR X.509 proxies (with
> restrictions)
>
> ### Open Questions:
>
>
> Q: There are WS interfaces for functional specifications that matter to PGI
> (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP
> based on HTTPS as mentioned above?
>
> Q: If not - are there any important functional interfaces (except support
> interfaces from AAs like classic VOMS) that do not support SOAP in the PGI
> ecosystem?
>
>
> Please feel free to comment but let the question of attributes+restrictions
> outside -  I propose to deal with it in separate threads because of their
> complexity.
>
>
> Take care,
> Morris
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------
> Morris Riedel
> SW - Engineer
> Distributed Systems and Grid Computing Division
> Jülich Supercomputing Centre (JSC)
> Forschungszentrum Juelich
> Wilhelm-Johnen-Str. 1
> D - 52425 Juelich
> Germany
>
> Email: m.riedel at fz-juelich.de
> Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel
> Phone: +49 2461 61 - 3651
> Fax: +49 2461 61 - 6656
>
> Skype: MorrisRiedel
>
> "We work to better ourselves, and the rest of humanity"
>
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> Vorstand: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender)
>
>
>
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090319/19af7838/attachment-0001.html