revised cert format and deprecation schedule

[Damien Miller]

Hi,

I just committed this:

>  - djm at cvs.openbsd.org 2010/04/16 01:47:26
>    [PROTOCOL.certkeys auth-options.c auth-options.h auth-rsa.c]
>    [auth2-pubkey.c authfd.c key.c key.h myproposal.h ssh-add.c]
>    [ssh-agent.c ssh-dss.c ssh-keygen.1 ssh-keygen.c ssh-rsa.c]
>    [sshconnect.c sshconnect2.c sshd.c]
>    revised certificate format ssh-{dss,rsa}-cert-v01 at openssh.com with
>    the following changes:
>
>    move the nonce field to the beginning of the certificate where it
>    can better protect against chosen-prefix attacks on the signature
>    hash
>
>    Rename "constraints" field to "critical options"
>
>    Add a new non-critical "extensions" field
>
>    Add a serial number
>
>    The older format is still supported for authentication and cert
>    generation (use "ssh-keygen -t v00 -s ca_key ..." to generate a v00
>    certificate)

so it seems like an opportune time to mention the deprecation rules that
I plan to follow for the certificate support as it is developed. 

There are basically three goals:

1) Develop OpenSSH certificates until they solve enough of the use-cases
   to be a compelling substitute for X.509 certs for a substantial
   number of users. This may require occasional backwards-incompatible
   changes.

2) Don't burn our early adopters by breaking their working
   configurations without ample warning.

3) Avoid having to be stuck with maintaining backwards compatibility
   code in perpetuity. This is for both workload and security reasons;
   more twisty compat code == more bugs.

So my working, self-imposed policy is to retain backwards compatibility
support for at least 13 months after the release that includes an
incompatible change. This duration is intended to let users sign certs
of one year duration and know that an OpenSSH release won't break them
in their life time. A corollary of this is that you shouldn't sign certs
that have an expiry date more than one year in the future if you want to
be able to upgrade to the latest version at will.

As an example, our next release will include the above incompatible
change and will likely be made some time around July. Following this
plan, I'll remove support for the v00 certificate format in the next
release after August 2011.

Hopefully this provides enough clarity for people to start using this
certificate support with some confidence that we won't break it at
random.

Naturally this policy is open for discussion, but I'd prefer that the
discussion happen *now* rather than when we are preparing for the
release in late 2011. So have at it :)

-d