OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] [RS Issue] HTTP connection taking longer than TTL


Matthew MacKenzie wrote:

> Farrukh,
>
> Application of SSL does not adequately replace request/response 
> signing while the application of SSL + Public Key authentication 
> between registries does.
>
> Sould Registry A trust Registry B because Verisign trusts Registry B, 
> or should RegA trust RegB because it received & accepted RegB's self 
> signed certificate as part of the federation protocol?


Think of Registry B (the requestor) as a Registered User of Registry A 
(the responder) . Registry  A trusts Registry B not because of verisign 
but because Registry B is a registered user of Registry A. In order for 
Registry B to be a registered user of Registry A, Registry B MUST have 
given its public key to Registry A and the public key root authority 
MUST be a trust anchor of Registry A.

This is normal Registry Client to Registry user registration and cert 
exchange requirements. The whole point of the section is that reg2reg 
communication follows precisely the same rules as client2reg 
communication where the requestor registry plays the same role as 
registry client.

What are we missing?

>
> -Matt
>
> Farrukh Najmi wrote:
>
>> Matthew MacKenzie wrote:
>>
>>> Farrukh Najmi wrote:
>>>
>>>> Matthew MacKenzie wrote:
>>>>
>>>>> Farrukh,
>>>>>
>>>>> I haven't hashed out a solution as of yet, but I was thinking 
>>>>> along the lines of adding  optional mutually authenticated SSL to 
>>>>> the Federation protocol.  This way, all members of a federation 
>>>>> would be trusted by virtue of their connections to each and other 
>>>>> being encrypted using keys that are trusted.  Some kind of self 
>>>>> signed certificate exchange like is done in ebMS might just allow 
>>>>> us to cut down some of the processing and comm (SSL/TLS can also 
>>>>> do some compression) overhead.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Good point.
>>>>
>>>> SSL based communication between Registry Client and Registry is 
>>>> already specified in section 10.3.1. I assume most 
>>>> registry-to-registry communication *WILL* be over SSL. Does that 
>>>> address the issue?
>>>
>>>
>>>
>>>
>>> Technically, yes, but I think we should mention that if 
>>> registry-to-registry communication is via mutually authenticated 
>>> SSL, requests and responses should not be signed.
>>
>>
>>
>> Agreed. I have replaced with following text:
>>
>> "9.2.7 Federations and Security
>>
>> Federated operations abide by the same security rules as standard 
>> operations against a single registry. However, federation operations 
>> often require registry-to-registry communication. Such communication 
>> is governed by the same security rules as a Registry Client to 
>> registry communication. The only difference is that the requesting 
>> registry plays the role of Registry Client. Such registry-to-registry 
>> communication SHOULD be conducted over a secure channel such as 
>> HTTP/S. Federation members SHOULD be part of the same SAML Federation 
>> if member registries implement the Registry SAML Profile described in 
>> chapter 11."
>>
>> Also added:
>>
>> 10.3.2.6 SOAP Message Security and HTTP/S
>>
>> When using HTTP/S between a Registry Client and a registry, SOAP 
>> message security MUST NOT be used. Specifically:
>>
>>    *
>>
>>      The Registry Client MUST NOT sign the request message or any
>>      repository items in the request.
>>
>>    *
>>
>>      The registry MUST NOT verify request or RepositoryItem signatures.
>>
>>    *
>>
>>      The registry MUST NOT sign the response message or any repository
>>      items in the response.
>>
>>    *
>>
>>      The Registry Client MUST NOT verify response or RepositoryItem
>>      signatures.
>>
>> Let me know if this is an adequate resolution of the issue. Thanks.
>>
>>>
>>> -Matt
>>>
>>> To unsubscribe from this mailing list (and be removed from the 
>>> roster of the OASIS TC), go to 
>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>
>>>
>>
>>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>
>


-- 
Regards,
Farrukh



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]