Re: What ASN.1 got right

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Mar 3, 2021 at 10:26 AM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Wed, Mar 03, 2021 at 12:34:19AM -0500, Phillip Hallam-Baker wrote:
> The practical limit on certificate lifespan is 48 hours renewed every 24
> unless you have a means of reliably getting trusted time into the client.

For server certificates five days is fine.  For clients you want
something akin to Kerberos.  Typical Kerberos installations issue 10
hour TGTs that are renewable (note: Kerberos sense of renewal) for a few
days, and after that the user has to type in their password or do
whatever MFA dance.

> I have been trying to find info on SSH user certs on and off for quite a
> while. Seems like an under-documented feature... They solve a big problem
> for me :-)

Honestly, they're not that interesting to me because of the limited
hierarchy they have.  I'd rather it were PKIX certs.  But at least they
got something right: subject naming, which they call principal names,
and which are just strings, freeform strings.  That means that if you
are migrating from some other system, you can keep that other system's
naming.

Thats all I need. Consider the case where Alice is using the Mesh to manage her SSH credentials. She has 5 devices she uses as a client and accesses 24 different servers.

Cryptographic hygiene requires each device have separate SSH credentials. Doing that with raw keys is beyond tedious because the admin tool has to log into every one of those 24 servers to update Alice's authorized keys file.

If the certificates are actually supported by GitHub etc, and can be used in the same spot that regular keys are, everything is tickety boo. If this is a theoretical feature supported by a fraction of the installed base... not so much.

And it looks like Github supports user certs but only in the paid enterprise version. Which doesn't work for my objective of getting the open source development ecosystem fixed...


Part of the plan here is that I want to get to a place where ALL code is signed. Especially code that is in development. Every build should be signed, every item in every assembly. Which is yet another reason why my Merkle Tree based DARE is vastly superior to WPACK.



 

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux