@izaya
-
@erincandescent @Gaelan @theresnotime @q @izaya yes, the algorithm is the same, but this isn't about the algorithms. e.g. X.509 trust establishment is heinously complex and error-prone in implementation and the trust establishment is why you're doing signed certificates to begin with.
-
@dequbed @Gaelan @theresnotime @q @izaya Sure, but SSH CAs sidestep that by… making it too simple. Because the longest possible path is Key -> CA
So my Root CA has to be online regularly to resign my actual keys, while if this were X.509 the root CA would be kept offline and I’d use the intermediate to regularly resign my end-user certificates.
(I know SSH has KRLs. They have even less deployment than X.509 CRLs, which suck)
-
@dequbed @Gaelan @izaya @q @theresnotime I’ve been down the X.509 mines and, yeah, it’s not simple and its full of legacy
But if you ignore some of the more escoteric features its not that complex.
-
@erincandescent @Gaelan @theresnotime @q @izaya So "if you don't actually implement X.509 it's not actually complex". That's true, but not a very good counter for the argument that "X.509 is a bad, overly complex standard we shouldn't use as-is".
-
@dequbed @Gaelan @theresnotime @q @izaya “If you implement the subset of X.509 people actually use - the mandatory parts of RFC 5280 - it’s not that complex”
And reinventing the wheel but simpler has a bit of a tendency to produce a standard lacking critical features, which either means its not fully fit for purpose or you’ll end up extendng it with those same features again