This topic is getting a bit bigger, perhaps let me sort first what issues we're talking about here. So to summarize the longer text that follows:
1. News::Article::NoCeM may embed an invalid hash algorithm declaration,
depending on the gpg program used by PGP::Sign, and possibly other
reasons.
2. News::Article::NoCeM uses a detached signature as an inline signature.
This is at least bad style, and possibly fragile.
3. There are issues with NoCeMs messages in general:
* For various reasons, they should better be multipart messages.
* The specification is rather vague on signing.
* There might be need to define good and acceptable hash algorithms.
4. Last, but certainly not least: The problem of very old PGP programs.
This here should mostly about the first item as this is real issue, and
something I'd like to see fixed in Debian 13 ("trixie") - I doubt it's
that urgent somebody would want to handle this in a point release.
The second is something of robustness although I'm not aware of any
actual problems caused by this. If it's easy to do, sure thing.
The rest should better be discussed elsewhere (news.admin.*,
inn-workers or whatever fits).
Russ Allbery wrote...
> I think this is a bug in News::Article::NoCeM. It is constructing an
> inline signed document using PGP::Sign's pgp_sign function, but pgp_sign
> creates detached signatures. Detached and inline signatures are subtly
> different, which has historically been the cause of all sorts of pain and
> suffering trying to deal with OpenPGP signatures.
#TIL
Now I'm wondering how many people know these signatures are different
things. I did not so I will not blame anyone for mixing them.
> This is explicitly called out in the PGP::Sign manual page, although it
> should be clearer since it implies the only issues are with whitespace
> munging, but it seems like there are more issues than just that.
Well, there's (emphasis mine)
| PGP::Sign - Create *detached* PGP signatures for data, securely
... but this doesn't help if people aren't even aware there is a
difference.
> I'm not sure where that leaves this bug, though. It's quite
> understandable that News::Article::NoCeM doesn't want to implement the
> annoying logic of figuring out the correct flags to call GnuPG, but if the
> expectation for NoCeM messages is that they use inline signatures (which I
> believe is the case, although ideally they should use multipart/signed and
> application/pgp-signature), PGP::Sign doesn't do that.
All I know about a specification of NoCeM messages is Tim Skirvin's FAQ
at [1]. Which does not go into detail about the actual signature
format. So we're left with perl-nocem and derive something like a
specification from there. And yes, perl-nocem expects an inline
signature. Enhancing it to process multipart message is not impossible
but it would take years until installations out there have followed.
> I do have other
> use cases for inline signatures currently, so I am not completely opposed
> to adding that support, although the more correct thing for me to do with
> those other use cases would be to switch to multipart/signed instead. At
> least the last time I looked, inline signatures were very poorly
> documented and standardized.
Of course I will not object if you would enhance PGP::Sign to properly
create inline signatures :-) But I read between the lines you'd prefer
to move into a different direction.
So perhaps doing this inside News::Article::NoCeM might be an option as
well, none that I like, though. But that for upstream to decide, I've
invited them to join this discussion.
> It's possible that this specific bug could be fixed if there were a way to
> pass the desired hash algorithm into the sign() method of PGP::Sign so
> that News::Article::NoCeM can force SHA-1 as a hash algorithm, thus making
> the signature match the headers. You suggested that in your original
> message. That's a bit more within the remit of PGP::Sign and I feel more
> comfortable supporting that. But I fear that may not be a full fix, since
> there's still the detached versus inline signature mismatch that I think
> is quite likely to produce more problems in the future.
As I'm already taking a lot of your time, mind to explain what problems
you are seeing here? If that might break NoCeM processing in general,
we should take precautions.
> (And of course
> there's also the problem that News::Article::NoCeM really should be using
> SHA-256, but that raises backwards compatibility issues. There are a lot
> of ancient PGPs out there in Usenet world.)
It looks like perl-nocem was written for GnuPG only. Are there any
other implementations that handle NoCeMs? My impression is news admins
who want to process NoCeMs must install GnuPG.
And the NoCeMs I generate, with SHA512, were - once the Hash: header
was correct - handled without a problem using GnuPG 1.4.10 from Debian
squeeze(sic!). So I cannot see a reason to limit hashing to SHA-256.
And if it's really about these decades-old PGP programs: As they are
not supported by perl-nocem, I cannot see they have relevance when it
comes to NoCeM processing. And, aside, for control message, I think
we're getting closer to the point where we no longer have to care:
While I don't claim to be an expert on (quantum) cryptography, it's
obvious those very old algorithms and short keys are the first to
become breakable with the advance of that technology, something that
might even happen within the next five years. And once the first forged
but cryptographically valid control messages float around, there is no
alternative to disable anything that is still based on that.
[ On the mandatory "Hash:" pseudo header ]
> This is ringing a vague bell. I think the issue with inline signatures is
> that since the document is stream-processed, the hash function that should
> be used for the text has to be specified *before* the signed body text.
> By the time the signature is read, it's too late; the body has already
> been consumed and hashed with the default hash algorithm, and the correct
> hash is no longer available.
Makes sense, explains why a mismatch is an error and not just a warning.
Thanks for shedding some light on this.
Regards,
Christoph
[1] http://www.cm.org/faq.html
signature.asc
Description: PGP signature
