Re: On specifying algorithms

On Mon, Sep 24, 2012 at 1:58 AM, GALINDO Virginie
<Virginie.GALINDO@gemalto.com> wrote:
> Ryan,
>
> Agree with your view that we are trying to define what should be the behavior of user agent in case it does implement it, plus suggesting the industry to have some systematic-if-possible implementation of a recommend list.
>
> About your proposal for giving better message around our algorithm choice and integration in the API.
> ---------------
> To that end, I propose we:
>  - Identify the core algorithms necessary to support the use cases, and standardize those
>  - Update the document to provide segmentation between "recommended"
> algorithms and "specified-but-not-recommended" algorithms
>  - Try to define a profile of the set of total algorithms that user agents can/should implement
>   - For example, this "might" be something like Level 1, Level 2, etc
>   - With the caveat that "any of these may be disabled by local policy", etc. But it does mean that, barring external crypto factors
> (eg: export regulations, local policy, etc), that a user agent will have a faithful and conforming implementation.
> ---------------
>
> Some comments :
> About identifying core algorithms to support use cases -->  I think we can definitely start from the list established before we went for the lowest common implemented algorithms, provided by Mike.

I'm not sure I follow this line. Mike's list captures the state of
intrinsic primitives, but it doesn't capture the use within protocols
or, more relevant to our work, the need in order to support the
various use cases members have proposed.

For example, just because a language does not implement certain
primitive natively does not mean developers aren't using it or don't
have a need for it. For example, for many Ruby devs, individual
developers were forced to re-implement CTR mode atop ECB, since Ruby
was only offering ECB. This is an example where there's a divergence
between the need/use for an algorithm and its implementation, and I'd
rather make sure we focused on specifying the algorithms that people
expect to use, rather than all the algorithms that may exist (eg:
Blowfish, Salsa20, etc)

> About segmentation between recommended and specified but recommended --> +1
> About definition of profile --> it seems to me that this exercise has already been done and lead to the paragraph "23.1. Recommended algorithms". And as such would not recommend that we start *now* again this discussion. Lets keep it as an idea for further exploration.

Sorry, I wasn't trying to suggest we re-open the subject, but I was
wanting to make sure that we were/are in agreement on what the
"Recommended algorithms" means.

It can mean "Recommended for implementations" or "Recommended for
developers". The danger is if those two sets don't overlap - for
example, "recommending" PKCS#1 v1.5 for implementations (it's widely
available, even on constrained / legacy platforms, and likely expected
by a number of "existing app" use cases), whereas for developers
(writing 'new' crypto), "recommended" would be using RSA-PSS/RSA-OAEP.

There's also danger in "Recommended for developers implementing
existing specifications" and "Recommended for developers implementing
new crypto" not overlapping.

I think a fair bit of the feedback circled around Twitter/Hacker
News/blogs (eg: none of which came through w3.org) seemed to focus on
"Recommended fro developers implementing new crypto", whereas I think
our current set of "Recommended" is more reflective of "Recommended
for implementations"

I suspect there is still room to add to the recommended list (to
satisfy needs for both new and existing protocols), as well as to
clarify in the spec what exactly "recommended" means, but I want to
make sure in the WG there is agreement on that, hence why I
enumerated.

Received on Monday, 24 September 2012 17:53:20 UTC