Re: Proposal for lc87 and lc55

Hi Marc.

* Marc Hadley <Marc.Hadley@Sun.COM> [2005-07-05 20:47-0400]
> >>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.

The issue I see is that underspecifying such a mechanism is going to
give us the appearance of an interoperable security mechanism that
most folks will want to use, as opposed to one which we are sure works
well.

If we were to include something which would be a recommended way to
establish trust, I would expect us to test that it works and at least
2 people can use it, i.e. do some tests at the CR level, and we would
probably want to have the security community review it, i.e. it looks
to me like a substantive change to the spec.

> >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 ?

Yes.

> >- 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.

What is a satisfactory trusted certificate authority? You mean that
it's trusted enough? I would have thought that trusted certificate
authority would have been enough.

> >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.

I understand your position. However, as I said, I don't think that the
current text is going to promote interoperability.

There's two ways of presenting this way of establishing trust: the
"you could do it like this in order to implement the model we've just
presented" way, or the "we could (and we encourage you to) use the
following mechanism: you MUST do this, and you MUST do that, etc."
spec-level — i.e. no questions left open — way. And I have the feeling
that right now we are in the middle.

The new text you've proposed improves the security model section, and
outlines clear principles about how to establish trust in EPRs. The
model provided shows that we have a good story about security, and I
don't think that we need to design a specific mechanism, i.e. I would
like us to go with the example route.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/