@izaya
-
@q @dequbed @erincandescent @theresnotime @izaya no wtf stop
-
@Gaelan @dequbed @erincandescent @theresnotime @izaya something something CA/BF
-
@q @Gaelan @dequbed @theresnotime @izaya there have been patches with X.509 support for a long time
in fact it might even be an RFC
-
@q @Gaelan @dequbed @izaya @theresnotime tbh it would be fine, let people reuse their existing CA infrastructure
-
@q @erincandescent @Gaelan @theresnotime @izaya oh really? Given that secsh has concluded a few years ago, under what wg? Or wg-independent?
-
@erincandescent @Gaelan @theresnotime @dequbed @izaya the room was seemingly not aware that was already an RFC
-
@q @Gaelan @theresnotime @dequbed @izaya Anyway X.509 is fiiine and it would sure be convinient to not have to run multiple PKIs.
-
@erincandescent @Gaelan @theresnotime @dequbed @izaya OpenSSH was in violent disagreement
-
@q @Gaelan @theresnotime @dequbed @izaya skill issue
-
@q @Gaelan @dequbed @izaya @theresnotime Lets be honest the main objection is “ASN.1 hard and icky” and
- ASN.1 is friend
- BER/DER is just not that hard
-
@erincandescent @Gaelan @theresnotime @q @dequbed @izaya I've worked with LDAP and I'm in maybe not violent but quite firm disagreement about ASN.1 being friend.
-
@viq @Gaelan @theresnotime @q @dequbed @izaya I’m not so sure how much this is about ASN.1 vs about LDAP which is this horrible stringly typed thing half-pretending to be ASN.1, giving the worst of both worlds
I was looking at an LDAP server the other day wondering what the OID defining a specific attribute was and IT WAS A STRING. WHY IS THAT POSSIBLE?!
-
@erincandescent @Gaelan @theresnotime @q @izaya Speaking with my cryptographer hat on, X.509 is not fine. And no, it's not about DER. ASN.1/DER is fine, it's about as horrible as all other binary formats.
-
@dequbed @Gaelan @theresnotime @q @izaya cryptographically they’re basically identical. Heck, I expected to be conceding “OK, SSH CAs use RSA with PSS instead of PKCS#1 v1.5 padding but no, we’re still using PKCS#1 v1.5 padding in a standard defined in 2018! :drgn_knife_angry:
So cryptographically there’s no difference between SSH
rsa-sha2-256
and X.509{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) sha256WithRSAEncryption(11)}
-
@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