Commit Graph

14 Commits

Author SHA1 Message Date
djm@openbsd.org 001aa55484 upstream: lots of typos in comments/docs. Patch from Karsten Weiss
after checking with codespell tool
(https://github.com/lucasdemarchi/codespell)

OpenBSD-Commit-ID: 373222f12d7ab606598a2d36840c60be93568528
2018-04-10 10:17:15 +10:00
djm@openbsd.org@openbsd.org c357eed5a5 upstream commit
typos in ECDSA certificate names; bz#2787 reported by
Mike Gerow

OpenBSD-Commit-ID: 824938b6aba1b31321324ba1f56c05f84834b163
2017-11-03 16:20:41 +11:00
djm@openbsd.org d40dbdc85b upstream commit
spell out that custom options/extensions should follow the
usual SSH naming rules, e.g. "extension@example.com"

Upstream-ID: ab326666d2fad40769ec96b5a6de4015ffd97b8d
2017-05-31 14:30:52 +10:00
djm@openbsd.org adb47ce839 upstream commit
mention that Ed25519 keys are valid as CA keys; spotted
by Jakub Jelen

Upstream-ID: d3f6db58b30418cb1c3058211b893a1ffed3dfd4
2017-05-17 11:25:22 +10:00
djm@openbsd.org fa58208c65 upstream commit
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

Upstream-ID: 7b535ab7dba3340b7d8210ede6791fdaefdf839a
2016-05-03 20:29:14 +10:00
Damien Miller 48348fc3b4 - djm@cvs.openbsd.org 2012/03/28 07:23:22
[PROTOCOL.certkeys]
     explain certificate extensions/crit split rationale. Mention requirement
     that each appear at most once per cert.
2012-04-22 11:08:30 +10:00
Damien Miller eb8b60e320 - djm@cvs.openbsd.org 2010/08/31 11:54:45
[PROTOCOL PROTOCOL.agent PROTOCOL.certkeys auth2-jpake.c authfd.c]
     [authfile.c buffer.h dns.c kex.c kex.h key.c key.h monitor.c]
     [monitor_wrap.c myproposal.h packet.c packet.h pathnames.h readconf.c]
     [ssh-add.1 ssh-add.c ssh-agent.1 ssh-agent.c ssh-keygen.1 ssh-keygen.c]
     [ssh-keyscan.1 ssh-keyscan.c ssh-keysign.8 ssh.1 ssh.c ssh2.h]
     [ssh_config.5 sshconnect.c sshconnect2.c sshd.8 sshd.c sshd_config.5]
     [uuencode.c uuencode.h bufec.c kexecdh.c kexecdhc.c kexecdhs.c ssh-ecdsa.c]
     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@
2010-08-31 22:41:14 +10:00
Damien Miller 1da6388959 - djm@cvs.openbsd.org 2010/08/04 05:40:39
[PROTOCOL.certkeys ssh-keygen.c]
     tighten the rules for certificate encoding by requiring that options
     appear in lexical order and make our ssh-keygen comply. ok markus@
2010-08-05 13:03:51 +10:00
Damien Miller d0e4a8e2e0 - djm@cvs.openbsd.org 2010/05/20 23:46:02
[PROTOCOL.certkeys auth-options.c ssh-keygen.c]
     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@
2010-05-21 14:58:32 +10:00
Damien Miller 2725c2193b - djm@cvs.openbsd.org 2010/05/01 02:50:50
[PROTOCOL.certkeys]
     typo; jmeltzer@
2010-05-10 11:56:14 +10:00
Damien Miller 4e270b05dd - djm@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@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@
2010-04-16 15:56:21 +10:00
Damien Miller fe588e3c84 - djm@cvs.openbsd.org 2010/03/03 22:50:40
[PROTOCOL.certkeys]
     s/similar same/similar/; from imorgan AT nas.nasa.gov
2010-03-04 21:52:00 +11:00
Damien Miller 25b97dd454 - (djm) [PROTOCOL.certkeys] Add RCS Ident 2010-03-03 10:24:00 +11:00
Damien Miller 0a80ca190a - OpenBSD CVS Sync
- djm@cvs.openbsd.org 2010/02/26 20:29:54
     [PROTOCOL PROTOCOL.agent PROTOCOL.certkeys addrmatch.c auth-options.c]
     [auth-options.h auth.h auth2-pubkey.c authfd.c dns.c dns.h hostfile.c]
     [hostfile.h kex.h kexdhs.c kexgexs.c key.c key.h match.h monitor.c]
     [myproposal.h servconf.c servconf.h ssh-add.c ssh-agent.c ssh-dss.c]
     [ssh-keygen.1 ssh-keygen.c ssh-rsa.c ssh.1 ssh.c ssh2.h sshconnect.c]
     [sshconnect2.c sshd.8 sshd.c sshd_config.5]
     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 sh/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@
2010-02-27 07:55:05 +11:00