3 ms·

>Ssh supports certificates as well as plain keys (a key with optional meta-data about validity, principals (users,servers etc). Wouldn't validity and principal

>Ssh supports certificates as well as plain keys (a key with optional meta-data about validity, principals (users,servers etc). Wouldn't validity and principals be best left to something like LDAP? I still haven't found anything that fits in the gap between "I only have one machine" and "I'm comfortable setting up Active Directory et-al". I like reading about all these systems but I've only got 5 or so machines under my direct control (although something that integrates with AWS would be nice for when I'm doing development work there)

e12e 10y ago
> Wouldn't validity and principals be best left to something like LDAP? Yes and no. Even with easier access to caching etc, ldap can still be rather fragile (no (readable) ldap; no login)[1] In general certificates need to be (proof of) principals (the entity that can prove ownership of the secret key X' corresponding to public key X" is X - where X is a uid (eg: e12e) Or a machine or service (login.example.com). But if your use case is simple, and some meta-data can be readily attached to the certificate, it's easy to add limits on where key X is valid from (source ip/host), have access to (services) and when (time of day) -- and adding an expiry. If policy is max lifetime of a week except for CA keys, then that greatly simplifies revocation lists. Generally "trust only this one CA" is simple, and allows moving capability (largely) to certificates. Centralised, on-line catalogs like LDAP make some things simpler. And there might be a balance: perhaps some basic group info is in the cert - and each service can base policy on that (email login ok 24/7 - certain other services only 8-16 -- although I can't think of a compelling need for the latter right now). [1] Of course one should check for revocations, but with an automated system to mint certificates, one can trade off with hour/day/week lifetimes. There was a recentish show hn: sharkey: https://news.ycombinator.com/item?id=12097992 https://news.ycombinator.com/item?id=12097992

e12e 10y ago

> Wouldn't validity and principals be best left to something like LDAP? Yes and no. Even with easier access to caching etc, ldap can still be rather fragile (no (readable) ldap; no login)[1] In general certificates need to be (proof of) principals (the entity that can prove ownership of the secret key X' corresponding to public key X" is X - where X is a uid (eg: e12e) Or a machine or service (login.example.com). But if your use case is simple, and some meta-data can be readily attached to the certificate, it's easy to add limits on where key X is valid from (source ip/host), have access to (services) and when (time of day) -- and adding an expiry. If policy is max lifetime of a week except for CA keys, then that greatly simplifies revocation lists. Generally "trust only this one CA" is simple, and allows moving capability (largely) to certificates. Centralised, on-line catalogs like LDAP make some things simpler. And there might be a balance: perhaps some basic group info is in the cert - and each service can base policy on that (email login ok 24/7 - certain other services only 8-16 -- although I can't think of a compelling need for the latter right now). [1] Of course one should check for revocations, but with an automated system to mint certificates, one can trade off with hour/day/week lifetimes. There was a recentish show hn: sharkey: https://news.ycombinator.com/item?id=12097992 https://news.ycombinator.com/item?id=12097992