Re: Algorithm Selections

Hi Joseph,

Thanks for the response. I think there a couple of levels of support for ECC
(and other algorithms) that could be provided:

- preferable for me - description of how to use ECC optionally within XML
encryption
- my second choice - ensure that the syntax selected for XML encryption can
support ECC.

I prefer the first one primarily because it addresses interoperability concerns
... two people who want to implement ECC will implement it the same way.

As an example, I think the decision whether or not to support key agreement is
relevant to the second point, since a key transport only solution would seem to
hinder extension of any syntax to support algorithms like Diffie-Hellman and EC
Diffie-Hellman - and this would seem mildly against the important extensibility
requirement.

Anyways ... I'm looking forward to participating in the standards development
process and discussing issues like these. Maybe it's too early in the discussion
to get into too much of this stuff. At some point I'll aim to bring in a
proposal on ECC (and of course an accompanying IPR disclosure).

Best regards. Simon





"Joseph M. Reagle Jr." <reagle@w3.org> on 11/27/2000 04:50:36 PM

To:   Simon Blake-Wilson/Certicom@Certicom
cc:   jimsch@nwlink.com, "'Xml-Encryption \(E-mail\)" <xml-encryption@w3.org>,
      Yongge Wang/Certicom@Certicom
Subject:  Re: Algorithm Selections




At 15:07 11/27/2000 -0500, Simon Blake-Wilson wrote:
>I'd like to suggest including ECC as an option ... either ECDH key
>agreement or
>ECIES key transport.

Hi Simon. I've represented this in the requirements document [1] as options
that can be considered by the WG.

>  My reasons:
>
>- ECC offers favourable performance compared to RSA in constrained
>environments
>like wireless ... particularly for private key operations like decryption.
>- In general it seems sensible to standardize a reasonable selection of
>algorithms to mitigate against the potential that some algorithms will be
>broken.

In the XML context, our goal is quick/easy interop by specifying an absolute
minimum that takes advantage of likely/exiting deployment, no IPR problems,
and a minimal amount of work that we'd have to co-opt with respect to
providing identifiers and keywraps. (Like xmldsig, the only requirement is
for a simple DSAKeyValue. Everything else could have been skipped). Anything
else must be specified under an external algorithm-identifier and namespace.

>Of course, there are patent issues with ECC, but I don't think this should
>be a
>reason to exclude optional ECC. Plus I think all the parties involved
>(certainly
>the party I work for) are fairly accustomed to committing to the usual
>'reasonable and non-discriminatory' terms that standards bodies' policies
>typically request.

Please, note that this WG will likely work under a more unencumbered IPR
policy than is typical [2].

___

[1]
[2] http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0023.html
"... Any intellectual property essential to implement specifications
produced by this Activity must be at least available for licensing on a
royalty-free basis..."

__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 27 November 2000 17:43:25 UTC