On 1/1/26 09:11, Simon Josefsson wrote: > I forget a major aspect the competition is doing worse than PGP: public > key distribution. While PGP key distribution has been a continous > problematic matter, it may be because the PGP ecosystem attempts to > address this problem and the other sign+verify technologies has given up > on solving it. > > Collin Funk <[email protected]> writes: > >> Doesn't Sigstore require a centralized Rekor instance? That was the >> impression I based on a very brief look at it previously. > > Yes, but I don't see that as a major problem since the transparency > model uses monitors/witnesses to keep instances honest. Same situation > with Sigsum really. Sigstore/Sigsum offers properties none of the other > solutions offer, so it may be a price that we need to pay to get those > properties. I think this is somewhat different compared to other > centralized services patterns, which is generally a deal-breaker.
Still, there is a chance that a rogue signature could be issued and weaponized well before the transparency service output could be checked. This is especially true if the signature output is used by an automated process. Detection is no substitute for prevention. > Demi Marie Obenour <[email protected]> writes: > >> I do think that better CMS/PKCS#7 implementations would be worth >> pursuing. This is because it is hard-coded into a huge number >> of applications that will be extremely difficult to change. >> These include: >> >> - Windows and UEFI Authenticode. >> - macOS and iOS code signing. >> - Legally binding CMS Advanced Electronic Signatures (CAdES). > > Why is compatibility with that an argument? I don't think CMS/PKCS#7 > offers anything compelling that PGP doesn't, and the complexity is > horrible (just think ASN1). CMS/PKCS#7 (and PGP for that matter) should not be used in _new_ designs. What I meant is that there are so many _existing_ uses that a good implementation is worthwhile. Using CMS is a mistake, but at this point, I'm not sure if it is always a _fixable_ mistake. The same goes for X.509. If CMS and X.509 can't be eliminated, I'd rather have one good implementation of both of them than a bunch of terrible ones. Parsing ASN.1 DER isn't actually that bad, at least once one gets over the various date-time and string formats. Parsing a single ASN.1 tag from a buffer is less than 40 lines of C code if one doesn't need to deal with tags over 0x1D. Creating ASN.1 requires a backwards postorder traversal, which is nasty but doable. The worst part of ASN.1 is that it encourages extremely complex encoding formats. X.509 adds very complex semantics on top of that, and CMS makes things even worse. >> Would it be possible to standardize some form of metadata for SSH signatures? >> >> CMS and OpenPGP support time-stamping countersignatures is critical. >> This is critical for some applications, notably Authenticode and CAdES. >> Should this be supported? > > Is that a critical feature for a signature format? Why not just design > a metadata format for that use-case, and sign the metadata using SSH > signatures? > > Feature creep in signature systems seems to be a big problem that > eventually turns them into a copy of PGP or CMS. Indeed it's generally better to include the metadata as part of the thing being signed, rather than as part of the signature itself. Extensibility is a curse as well as a blessing, and in cryptography my understanding is that the first is usually the most common. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
