[ietf-dkim] Charter bashing...

[Hallam-Baker, Phillip]

> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Stephen Farrell
> 4. The phrase "minimal change" just doesn't belong in a 
> charter for a charter like this - its use just offers a very 
> handy stick for anyone who wants to beat up on the charter. I 
> believe that the real requirement isn't so much minimal 
> change, but that all changes need to take into account that 
> there is already deployed technology for this purpose and we 
> should not make the (required) migration any more difficult 
> than needs to be the case. Its implicit in any WG charter (or 
> ought be) that gratuitous changes aren't what we do - trying 
> to hammer it home in this way is just counter productive.

I agree, what people want is to avoid unnecessary backward
incompatibility. The type of thing that happens when someone decides
that all URLs should begin with the string URL: to be valid. According
to one 'official' spec we should write URL:http://www.ietf.org/ 

I have seen four specs that look like DKIM, there is no real difference
between them tecnically. One has significant deployment, the others do
not. That the best way to choose all things being equal.


> I'd also suggest some improvements, along the following lines:
> 
> 5. Add a new deliverable - a dkim overview informational rfc 
> which is not on the critical path (i.e. can be delivered 
> last) and which can contain all of the "sales pitch" and "my 
> favourite useful extension" bits of text we accumulate as we 
> go. In a couple of contexts I've found this to be a useful 
> way to insulate the core specs from well-intentioned but 
> currently distracting contributions. Its also a good way to 
> archive those truly useful contribitions which are basically 
> too early but can be re-considered once the core deliverables 
> have been done.

Good place to put patent busting comments as well. If we don't write
down the DNS revocation hack some troll will patent it.


> 6. I would allow for the later addition of a few deliverables 
> which can handle changes to ciphersuites, improved/fixed 
> canonicalisation, and/or alternative ways to distribute publc 
> keys. The logic here is that these are areas where specs. 
> have been shown to need additional malleability over the last 
> few years, due to developments in crypto (e.g. hash fncs>, 
> the discovery of broken c14n (e.g. xml sig) or just because 
> some specs don't arrive on time (e.g. scvp). I wouldn't start 
> by planning to have any of these types of spec written but 
> would like the charter to specifically give the chairs the 
> flexibility to allow new drafts in these specific areas if 
> they do end up being needed.

IETF is currently a three round deal. In the near future it may be
reduced to two rounds. I think we can add the additional ciphers in at
the DRAFT standard stage without introducing delay.

We are unlikely to want to do anything other than RSA with SHA1 in the
short term. In the medium term we expect to have a new hash algorithm.
We will need to consider ECC.