clarify encoding of options/extensions; bz2389

PROTOCOL.certkeys: update reference from IETF draft to RFC

Also fix some typos.
ok djm@

correct extension name "no-presence-required" => "no-touch-required"

document "verify-required" option

document the "no-touch-required" certificate extension;

ok markus, feedback deraadt

mention ssh-ed25519-cert-v01@openssh.com in list of cert key type
at start of doc

Improve strictness and control over RSA-SHA2 signature types:

In ssh, when an agent fails to return a RSA-SHA2 signature when
requested and falls back to RSA-SHA1 instead, retry the signature to
ens

Improve strictness and control over RSA-SHA2 signature types:

In ssh, when an agent fails to return a RSA-SHA2 signature when
requested and falls back to RSA-SHA1 instead, retry the signature to
ensure that the public key algorithm sent in the SSH_MSG_USERAUTH
matches the one in the signature itself.

In sshd, strictly enforce that the public key algorithm sent in the
SSH_MSG_USERAUTH message matches what appears in the signature.

Make the sshd_config PubkeyAcceptedKeyTypes and
HostbasedAcceptedKeyTypes options control accepted signature algorithms
(previously they selected supported key types). This allows these
options to ban RSA-SHA1 in favour of RSA-SHA2.

Add new signature algorithms "rsa-sha2-256-cert-v01@openssh.com" and
"rsa-sha2-512-cert-v01@openssh.com" to force use of RSA-SHA2 signatures
with certificate keys.

feedback and ok markus@

show more ...

lots of typos in comments/docs. Patch from Karsten Weiss after checking
with codespell tool (https://github.com/lucasdemarchi/codespell)

typos in ECDSA certificate names; bz#2787 reported by Mike Gerow

spell out that custom options/extensions should follow the usual SSH
naming rules, e.g. "extension@example.com"

mention that Ed25519 keys are valid as CA keys; spotted by
Jakub Jelen

correct some typos and remove a long-stale XXX note.

add specification for ed25519 certificates

mention no host certificate options/extensions are currently defined

pointed out by Simon Tatham

explain certificate extensions/crit split rationale. Mention requirement
that each appear at most once per cert.

Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and
host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer
better performance than plain DH and DSA at the same equiv

Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and
host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer
better performance than plain DH and DSA at the same equivalent symmetric
key length, as well as much shorter keys.

Only the mandatory sections of RFC5656 are implemented, specifically the
three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and
ECDSA. Point compression (optional in RFC5656 is NOT implemented).

Certificate host and user keys using the new ECDSA key types are supported.

Note that this code has not been tested for interoperability and may be
subject to change.

feedback and ok markus@

show more ...

tighten the rules for certificate encoding by requiring that options
appear in lexical order and make our ssh-keygen comply. ok markus@

Move the permit-* options to the non-critical "extensions" field for v01
certificates. The logic is that if another implementation fails to
implement them then the connection just loses features rath

Move the permit-* options to the non-critical "extensions" field for v01
certificates. The logic is that if another implementation fails to
implement them then the connection just loses features rather than fails
outright.

ok markus@

show more ...

typo; jmeltzer@

revised certificate format ssh-{dss,rsa}-cert-v01@openssh.com with the
following changes:

move the nonce field to the beginning of the certificate where it can
better protect against chosen-prefix a

revised certificate format ssh-{dss,rsa}-cert-v01@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 support for authentication and cert generation
(use "ssh-keygen -t v00 -s ca_key ..." to generate a v00 certificate)

ok markus@

show more ...

s/similar same/similar/; from imorgan AT nas.nasa.gov

Add RCS Ident

Add support for certificate key types for users and hosts.

OpenSSH certificate key types are not X.509 certificates, but a much
simpler format that encodes a public key, identity information and
som

Add support for certificate key types for users and hosts.

OpenSSH certificate key types are not X.509 certificates, but a much
simpler format that encodes a public key, identity information and
some validity constraints and signs it with a CA key. CA keys are
regular SSH keys. This certificate style avoids the attack surface
of X.509 certificates and is very easy to deploy.

Certified host keys allow automatic acceptance of new host keys
when a CA certificate is marked as trusted in ~/.ssh/known_hosts.
see VERIFYING HOST KEYS in ssh(1) for details.

Certified user keys allow authentication of users when the signing
CA key is marked as trusted in authorized_keys. See "AUTHORIZED_KEYS
FILE FORMAT" in sshd(8) for details.

Certificates are minted using ssh-keygen(1), documentation is in
the "CERTIFICATES" section of that manpage.

Documentation on the format of certificates is in the file
PROTOCOL.certkeys

feedback and ok markus@

show more ...