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.
Most WGs (S/MIME, PKIX, TLS) seem to do this via additional RFCs. Not
sure why but it does seem to be easiest that way when you have to do
it.
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.
Yes - it could be that we define rsa-sha1 signing and yet another
problem with sha1 turns up late in the day. At that point we might
want to try rsa-sha256 or rsa-NIST2006 or whatever. I also agree
that an ECC version may be useful longer term (if the IPR were to
be ok there). More likely though (IMO) is that we make some mistakes
in C14N which we want to correct via a secondary spec (since we may
at that point have people with deployed dkim services based on the
buggy C14N). Same as happened with xmlsig really. In that case I'd
like to not have to re-charter to add the required additional spec.
Finally, I'd like to be able to allow public key distribtion drafts
once we've gotten the core protocol out of the way, again without
re-chartering. (Though for this last, I could accept that re-chartering
might be appropriate.)
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org