summaryrefslogtreecommitdiff
path: root/PROTOCOL.certkeys
Commit message (Collapse)AuthorAgeFilesLines
* upstream: PROTOCOL.certkeys: update reference from IETF draft tonaddy@openbsd.org2021-06-061-12/+11
| | | | | | | | | RFC Also fix some typos. ok djm@ OpenBSD-Commit-ID: 5e855b6c5a22b5b13f8ffa3897a868e40d349b44
* upstream: correct extension name "no-presence-required" =>djm@openbsd.org2021-06-041-5/+13
| | | | | | | | "no-touch-required" document "verify-required" option OpenBSD-Commit-ID: 1879ff4062cf61d79b515e433aff0bf49a6c55c5
* upstream: document the "no-touch-required" certificate extension;djm@openbsd.org2019-11-251-1/+8
| | | | | | ok markus, feedback deraadt OpenBSD-Commit-ID: 47640122b13f825e9c404ea99803b2372246579d
* upstream: mention ssh-ed25519-cert-v01@openssh.com in list of certdjm@openbsd.org2018-11-161-1/+2
| | | | | | key type at start of doc OpenBSD-Commit-ID: b46b0149256d67f05f2d5d01e160634ed1a67324
* upstream: Improve strictness and control over RSA-SHA2 signaturedjm@openbsd.org2018-07-031-4/+16
| | | | | | | | | | | | | | | | | | | | | | | 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@ OpenBSD-Commit-ID: c6e9f6d45eed8962ad502d315d7eaef32c419dde
* upstream: lots of typos in comments/docs. Patch from Karsten Weissdjm@openbsd.org2018-04-101-2/+2
| | | | | | | after checking with codespell tool (https://github.com/lucasdemarchi/codespell) OpenBSD-Commit-ID: 373222f12d7ab606598a2d36840c60be93568528
* upstream commitdjm@openbsd.org@openbsd.org2017-11-031-4/+4
| | | | | | | typos in ECDSA certificate names; bz#2787 reported by Mike Gerow OpenBSD-Commit-ID: 824938b6aba1b31321324ba1f56c05f84834b163
* upstream commitdjm@openbsd.org2017-05-311-1/+7
| | | | | | | spell out that custom options/extensions should follow the usual SSH naming rules, e.g. "extension@example.com" Upstream-ID: ab326666d2fad40769ec96b5a6de4015ffd97b8d
* upstream commitdjm@openbsd.org2017-05-171-7/+8
| | | | | | | mention that Ed25519 keys are valid as CA keys; spotted by Jakub Jelen Upstream-ID: d3f6db58b30418cb1c3058211b893a1ffed3dfd4
* upstream commitdjm@openbsd.org2016-05-031-10/+32
| | | | | | | | | | | | 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
* - djm@cvs.openbsd.org 2012/03/28 07:23:22Damien Miller2012-04-221-3/+12
| | | | | | [PROTOCOL.certkeys] explain certificate extensions/crit split rationale. Mention requirement that each appear at most once per cert.
* - djm@cvs.openbsd.org 2010/08/31 11:54:45Damien Miller2010-08-311-29/+60
| | | | | | | | | | | | | | | | | | | | | | | | | [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@
* - djm@cvs.openbsd.org 2010/08/04 05:40:39Damien Miller2010-08-051-4/+8
| | | | | | [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@
* - djm@cvs.openbsd.org 2010/05/20 23:46:02Damien Miller2010-05-211-11/+24
| | | | | | | | | | [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@
* - djm@cvs.openbsd.org 2010/05/01 02:50:50Damien Miller2010-05-101-2/+2
| | | | | [PROTOCOL.certkeys] typo; jmeltzer@
* - djm@cvs.openbsd.org 2010/04/16 01:47:26Damien Miller2010-04-161-29/+44
| | | | | | | | | | | | | | | | | | | | | | | [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@
* - djm@cvs.openbsd.org 2010/03/03 22:50:40Damien Miller2010-03-041-2/+2
| | | | | [PROTOCOL.certkeys] s/similar same/similar/; from imorgan AT nas.nasa.gov
* - (djm) [PROTOCOL.certkeys] Add RCS IdentDamien Miller2010-03-031-0/+2
|
* - OpenBSD CVS SyncDamien Miller2010-02-271-0/+191
- 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@
View Lorry Controller Status