[Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ

[Morris Riedel]

Yes,

 

  that’s what I meant – I guess we just need two because of some legacy
production systems?!

 

 

When I think about opening a TLS I think the following options exist:

 

 

(A)

I use a GSI Proxy to establish a GSI-based TLS connection – each hop creates
a new proxy-pair.

 

(B)

I use a OpenSSL proxy to establish an OpenSSL-based proxy TLS connection
(which included C) – each hop creates new proxy-pair

 

(C)

I use a full end-entity certificate to establish a TLS connection

 

 

Would you agree on this one with me and what do others think, e.g. gLite?

 

 

Thanks,

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)

 

From: weizhong qiang [mailto:weizhongqiang at gmail.com] 
Sent: Friday, March 27, 2009 1:46 PM
To: Morris Riedel
Cc: Aleksandr Konstantinov; pgi-wg at ogf.org
Subject: Re: [Pgi-wg] Sec: Agreement on
attributetransportmechanismsforAttrAuthZ

 

 

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

Hi,

>- Of course. "Full certificate" is just an extreme case of proxy

certificate - like table without legs.

Unfortunately, we heard earlier that this is not generally the case since
GSI proxy-based TLS changes also the wire or handshaking process while I
agree with end-entity TLS is a subset (as chain length 0 proxy) of normal
TLS.

However, in practical works I have done in scenarios - I learned we have to
support both. So I see that we have to support both?!


There are at least two "both" from my understanding here:
1, in terms of certificate itself, both full X.509 and proxy certificate;
and support means the verification of certificate, and only normal TLS wire
protocol is used.
Which you agree from your sentence, I think.

2, in terms of wire protocol, both TLS and GSI, which practically are
incompatible.
I guess your question is about this one.
I propose we can have two profiles about this, while mentioning GSI (wire
protocol) profile is only for legacy reason, but is not recommended.


Weizhong Qiang
 

 


Take care,
Morris

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090327/fe3edf27/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090327/fe3edf27/attachment-0001.bin