secure sign & encrypt

[Robert J. Hansen]

> In the end it all boils down that people (or, at least I) automatically
> put different meanings to a message, depending on the source of the

If you decide to (foolishly) infer that crypto means something that it 
doesn't, which no reputable source will tell you it does, then that 
reflects more on your own lack of understanding than a flaw in the 
protocol.  Ignorance is the Achilles' heel of every protocol, and your 
proposed fix does not fix the protocol--the protocol's not broken--it just 
makes the protocol come into line with how you think the protocol Ought To 
Be.

> Concerning RFC compliance:
> from rfc2440, section 5.2.3.1:
> ======
>      An implementation SHOULD ignore any subpacket of a type that it
>      does not recognize.
> ======

Note well that sentence.  SHOULD, not MUST.  For every program which 
correctly and properly implements RFCs, there are easily a couple of dozen 
which just barely manage to get the MUSTs implemented.  When I was working 
at McLeodUSA, they had me working on a project to reimplement RFC1991 
(Classic PGP) in-house so they could get around the licensing terms.  
(Never mind that the license fees to RSA and IDEA were prohibitive... 
management at its finest.)  Given the tremendous time constraints I was 
under, I was doing really, really well just to get the MUSTs.

If this extension gets implemented it _will_ break interoperability with 
other OpenPGP implementations (even if I don't know offhand which ones it 
will break), and we'll be the ones who will be responsible.  All for no 
effective increase in security.

> Also - although I'm in no way involved with writing RFCs - the RFC
> documents have been known to be revised and extended from time to time.

Yes, by working groups.  If you want the RFC changed, there's a process in 
place for it; take it to the IETF and make the sales pitch there.  GnuPG 
is not the place to be embracing-and-extending the RFC.

I don't know how much clearer I can make it here, really.