4 ms·
Does anyone have a link to a run-down on reasons to prefer this format over CMS? The community's been iterating on that for ~20 years now (RSA PKCS#7, RFC 3852,
by hoistbypetard 10y ago
Does anyone have a link to a run-down on reasons to prefer this format over CMS? The community's been iterating on that for ~20 years now (RSA PKCS#7, RFC 3852, RFC 5652, and a pile of other formats/protocols built on top of these) and so far nothing is jumping out to make me think this is an improvement.
- throwaway2048 10y agoNot using ASN.1 is a massive improvement. ASN.1 is turing complete. That means you cannot computationally decide if two certificates are equivilent, assuming advanced enough fuckery. This is very very bad. ASN.1 (which is also used in x509) is a catastrophicly awful format for encoding certificates or other crypto operations, and is the direct cause of a huge amount of SSL/TLS security issues.
- nickpsecurity 10y agoI recommend against ASN.1 as well. However, Galois Inc did a high-assurance implementation of a good chunk of it: http://www.ieee-stc.org/proceedings/2006/pdfs/AA1414.pdf http://www.ieee-stc.org/proceedings/2006/pdfs/AA1414.pdf
- nullc 10y ago> ASN.1 is turing complete. ASN.1 is a horror show, and the actual implementations of it that are available are even worse-- I've still yet to find an open source implementation of BER that strictly matches the spec, correctly accepting and interpreting all values that should be accepted and rejecting all values that should not... but I believe that you're joking about "turing complete". ... But ASN.1 is so bad that I'm not completely sure. Can you confirm or cite?
- userbinator 10y agoASN.1 is most definitely NOT Turing-complete.
- niftich 10y agoASN.1 as used by Internet PKIX X.509 uses [1] a form known as DER (Distinguished Encoding Rules) which provide a canonical way encoding any particular value such that any particular value can take only one specific form. [1] https://tools.ietf.org/html/rfc5280#section-4.1 https://tools.ietf.org/html/rfc5280#section-4.1
- unscaled 10y agoI can think of at least 3 reasons for not using CMS/PKCS #7: 1. CMS is using ASN.1 as others have mentioned. That alone is a deal-breaker and a major reason CMS implementation are hard, uncommon, and ever-so-slightly incompatible. 2. CMS requires certificates, which are harder to generate, verify and deal with than simple public keys. 3. CMS allows you to use any combination of ciphers, including weak one. Experience with TLS told us that this flexibility is NOT good feature when it comes to crypto standards. Besides that, all the reasons the rationale raised against PGP also reamin true for CMS: https://saltpack.org/pgp-message-format-problems https://saltpack.org/pgp-message-format-problems
- jnwatson 10y agoPublic keys without certificates have no meaning. Certificates bind public keys with information like identity and permissions. That's pretty important for cryptography.