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. 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). > 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. /Simon
signature.asc
Description: PGP signature
