Re: Proposal for lc87 and lc55

On Jul 5, 2005, at 3:44 AM, Hugo Haas wrote:
>
> Please find comments and questions below.
>
Responses similarly inlined.

>
>> -- cut here --
>>
>> X. Security Considerations (Core)
>>
> […]
>
>>
>> (ii) Users of EPRs should only use EPRs from sources they trust. The
>> required trust has two aspects:
>>
>> (a) that the EPR was obtained from a trusted source
>>
>
> This seems circular: "Users of EPRs should only use EPRs from sources
> they trust. […] (a) that the EPR was obtained from a trusted source"
>
> How about:
>
>   (ii) Users of EPRs should validate the trustworthiness of an EPR
>   before using it, considering the two following aspects:
>
Works for me.

>
>> (b) that it was obtained from a source with authority to represent
>> the [destination] of that EPR.
>>
>
> EPRs don't have a [destination] property. Did you mean [address]?

Yes, s/[destination]/[address]/

> Did
> you mean the (physical) destination of the message, considering that
> [address] may be a logical address?
>
I don't think we've really locked down what we mean by logical  
address vs physical address so I  don't see any value in  
differentiating here.

> Note that there are other instances of "[destination] of that EPR"
> below, too.
>

OK.

> […]
>
>> X.X Establishing EPR Trust
>>
>> There are many mechanisms that could be used to supply proof that a
>> message sender has authority to represent the [destination] of EPRs
>> supplied within the message. This section defines one such mechanism
>> that SHOULD be supported.
>>
>
> Until now, the proposed text was written in casual English, and all of
> a sudden there's an uppercase SHOULD. This seems to be a problem as…
>
Right, the idea is that the proposed mechanism be one that most folks  
implement rather than just being an example of how things could be done.

>
>> When using this mechanism, a message MUST include a WS-Security[WS-
>> Security] header that contains XML digital signatures binding the
>> wsa:ReplyTo and wsa:FaultTo elements to the SOAP message using an X.
>> 509 certificate issued by a mutually trusted certificate authority
>> (establishment of certificate authority trust is outside the scope of
>> this specification) for the domain addressed by the [destination] of
>> the EPR. Possession of a certificate signed by a trusted certificate
>> authority for the domain addressed by the [destination] of the EPR
>> provides a level of confidence that the message sender has authority
>> to represent the [destination].
>>
>
> … two sentences to define a mechanism that is recommended seem very
> light.
>
Fair enough.

> Some arbitrary choices have been made, such as the use of X.509. Why
> is that?
>
X.509 is a commonly implemented PKI and the proposed mechanism relies  
on the presence of a mutually trusted certificate authority.

> It also calls for questions like (having received some help from my
> colleague Thomas Roessler, copied on this email; note that this list
> is not exhaustive):
> - how is the domain matching done? A reference to PKIX should be added
>   as there seem to be several ways of establishing this, e.g.
>   subjectAltName extension from PKIX vs. Common Name part of the
>   Subject, I am being told.

Sounds reasonable.

> - does this mean a certificate that refers to the exact domain name,
>   or do you want to apply certificates to arbitrary subdomains?

You mean should I trust that a certificate for example.com enables  
the signer to speak for ex1.example.com ?

> - why does the certificate need to be mutually trusted? Only the EPR
>   user should need to trust the signature.
>
I see what you mean. Perhaps satisfactory is a better word than  
trusted for the EPR issuer.

> Therefore, I believe that this mechanism should be presented as an
> example of how to establish trust rather than as a recommended
> technique.
>
A recommended technique stands a better chance of adoption and hence  
of promoting interop than an example so I'd prefer to keep it that way.

> Here is a concrete proposal to address this:
> - replace "This section defines one such mechanism that SHOULD be
>   supported" by "Below is an example of such a mechanism"
> - replace "When using this mechanism, a message MUST include a
>   WS-Security header" by "Use a WS-Security header"
> - remove "mutually" (see comment above)
>
>
>> X.X Additional Security Considerations
>>
>> The wsa:isReferenceParameter attribute is only meaningful on SOAP
>> headers. Message processors should consider its appearance  
>> elsewhere in
>> a SOAP message as a possible attack.
>>
>> Message processors should consider elements from the soap11 and  
>> soap12
>> namespace appearing as reference parameters in an EPR as a possible
>> attack.
>>
>> <ednote>We should discuss whether WS-Addr elements as reference
>> parameters also pose a risk. Certainly being able to include an
>> Action, ReplyTo or FaultTo as a ref param seems to open up some
>> interesting avenues for attack.</ednote>
>>
>
> How about the text used for LC77[2]?
>
Yes, I'd forgotten about issue lc77.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.