Re: draft-brown-eppsig, was: Standard Extensions

On 24/08/12 10:42, Gavin Brown wrote:
> On 24/08/2012 02:29, James Mitchell wrote:
>> I am having trouble identifying the problem that this extension aims to
>> solve. Is the use case for this consider transport mechanisms other than
>> TCP with TLS (and client authentication)? Perhaps someone can enlighten me?
>
> The use cases I came up with are described in the draft. ⌘C, ⌘V:
>
> 2.  Use Cases
>
>     Digital signatures may be useful in a number of scenarios, such as:
>
>     1.  a registry which charges a very high fee for object provisioning,
>         where the cost of refunds and chargebacks is sufficiently high
>         that it is necessary to deter frivolous registration requests.
>
>     2.  a registry operating at a high level of security, where defence-
>         in-depth and the need to provide a full audit trail require
>         strong authenticity of provisioning requests.
>
>     3.  future extensions to EPP may permit use of transport protocols
>         such as SMTP [RFC5321] or XMPP [RFC6120], which cannot provide
>         end-to-end authenticity of frames.
>
> G.
>

Hi,

well, I do not consider myself a security expert, but I don't see how XML 
signatures would be beneficial, especially in the context of its overwhelming 
complexity, which is considered as an attack vector to its security.

re 1: this scenario assumes that the registrar is not capable keeping his 
credentials for accessing the registry in a safe place, so that they can be 
misused by non-authorized employees. But then the storage of the private key for 
the signature is likely to be similar unsafe.

re 2: I don't think that such use cases should not be integrated into a 
protocol, esp. as this can be done on-top. Transport integrity is guaranteed by 
TLS (RFC 5734). If this is not sufficient, a different transport protocol can be 
implemented.

re 3: I think one should follow the principle of separation of concerns, or, 
differently said, on the layer model. If the base transport protocol does not 
support the desired security or cannot be extended appropriately (e.g. S/MIME 
for SMTP), one should better ask in the first place why it should be used at all.

Just my two cents,

Klaus


_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg