Re: Re: Best practices for signature verifcation

[Demi Marie Obenour <demiobenour () gmail com>]

On 1/4/26 06:56, Peter Gutmann wrote:
> Demi Marie Obenour writes:
>
> > My understanding is that most people here are looking for purpose-built
> > formats, rather than specializations of general-purpose formats. For
> > instance, here is something based on OpenSSH signatures as a building block.
>
> You're still missing the point: The exact bit-bagging scheme used is
> irrelevant, firstly because we already have a universally-deployed one
> (OpenPGP and its tooling via GPG) and secondly because it's something that any
> vaguely competent cryptoplumber should be able to throw together in under a
> minute and as long as it doesn't involve XML in which case you may as well
> pre-register the CVEs before you start it should be fine.

Given https://gpg.fail, I don't think that the bit-bagging scheme is
a solved problem.  I'm not aware of any OpenPGP or CMS implementation
that is not incredibly complicated.  Even a formally verified one
might be implementing a flawed spec.

> What we don't have is all the stuff needed to address the "keys and signatures
> fall from the sky and the timestamping fairy blesses them" issue.  We've got,
> for example, the Debian CA-root-equivalent keyring, but how are the resulting
> signatures timestamped?  How are the TSA keys distributed?  How is a signature
> on malware revoked once it's been timestamped?  What happens if the signing
> key is revoked due to compromise but after its been countersigned by a TSA
> (this is different to revoking a signature on malware)?  etc.

That I totally agree with.

To answer your last question: I believe that it is sufficient for the
TSA to sign the public key, hash algorithm, and signature algorithm
used to make the signature, as well as the signature itself.  Changing
the message will cause the hash to be an essentially random value,
which will fail signature verification with overwhelming probability.
Otherwise, the signature algorithm would be vulnerable to brute-force
attack.  This argument holds even if the private key of the signer
(but not the TSA, of course) becomes compromised.

> That would in fact be one argument for going with CMS, you can use any off-
> the-shelf TSA whereas doing it with OpenPGP would require an org like the
> Linux Foundation to run a PGP TSA, but I get the feeling the GPL-or-death
> subgroup won't agree to the use of CMS.

I'm fine with CMS *if* there is an implementation that is permissively
licensed and *obviously* correct.  I don't want a CMS equivalent
of <https://gpg.fail>.  I don't think this is possible, though,
because CMS is such a complex standard.

> As an aside, is anyone aware of a single-source design document for what
> Authenticode does?   There's a million web pages related to the business of
> selling signing certs, and less than a million on using it, but I can't find a
> single-source design doc, just lots of stuff in various places that I've
> picked up over the years.  By "single-source doc" I mean something that
> addresses all of the above issues and related ones in one place.

Microsoft has a spec, and it does use a fairly reasonable subset
of CMS, but it is still quite complex.  Much of the complexity is
likely in the X.509 certificate handling, though.  This assumes one
uses a special-purpose CMS implementation and not a general-purpose,
overcomplicated one.

Being able to assume ASN.1 DER (or at least no indefinite-length
encodings) would makes things much simpler too.  One can work around
this with a stack-based parser, though.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature