headers
David Shaw | 1 Apr 2004 03:13

Re: [ISSUE] Signing things that aren't obvious how to hash


On Wed, Mar 31, 2004 at 01:09:33PM -0800, Hal Finney wrote:
> 
> David Shaw writes:
> > Section 5.2.4 says:
> >
> >     The signature data is simple to compute for document signatures
> >     (types 0x00 and 0x01), for which the document itself is the data.
> >
> > How about:
> >
> >     The signature data is simple to compute for document signatures
> >     (types 0x00 and 0x01), for which the document itself is the data.
> >     When the document is not represented as a Literal Message, the
> >     entire OpenPGP Message is the data.  See section 10.2 for the
> >     formal definition of Literal and OpenPGP messages.
> 
> One comment, after helping many people over the years implement OpenPGP
> compliant code, I suggest we take out any claims in the document that
> any part of it is "simple".

Good point. ;)

The original "problem" here is that the grammar defines a particular
packet arrangement that the draft doesn't explain how to generate:

  Signature Packet, OpenPGP Message

and
(Continue reading)

Permalink | Reply | 501 comments |
headers
David Shaw | 1 Apr 2004 03:25

Re: [ISSUE] End-of-line whitespace in 0x01 sigs


On Wed, Mar 31, 2004 at 08:51:57PM +0100, iang <at> systemics.com wrote:

> I suggest that if there is to be a change, then there
> might need to be some note reflecting that change.
> Something like:

[..]

>          Note. Some non-conforming implementations may calculate over 
>          canonical lines with trailing whitespace removed (spaces
>          and tabs).

Rather than putting this here in section 5.2.1, put it in the
implementation notes section at the end (section 14):

     * Historically there has been some variability in end of line
       whitespace removal from cleartext signatures.  Specifically,
       some implementations do not count the tab character (0x09) as
       whitespace at the end of the line.  These signatures are not
       OpenPGP compliant, but MAY be accepted.

     * Earlier versions of this standard required removing end of line
       whitespace from 0x01 canonical text signatures.  This is no
       longer true, and such signatures are not OpenPGP compliant, but
       MAY be accepted.

David
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Shaw | 15 Apr 2004 17:46

"Yes, I can handle PGP/MIME"


The PGP/MIME vs inline discussion seems to be on an up-cycle, and it
showed up on both the PGP and GnuPG mailing lists in the past week.

I don't mean to revisit the debate itself, so suffice to say that some
people use it, some people don't use it, some people can't use it, and
there are difficulties when a user sends PGP/MIME to someone who can't
handle it.

Given all that, would there be some benefit in a standard way for a
user to advertise that he can handle PGP/MIME?  Specifically, a
"features" subpacket bit to say "I can handle PGP/MIME".

It's important not to read too much into such a feature bit.  Having
the bit set does not mean that PGP/MIME must be used, and having the
bit unset does not mean that PGP/MIME must not be used.  A PGP/MIME
bit, rather like the MDC bit, simply means that the user is capable of
handling a PGP/MIME message.  How a sender handles that extra
information is up to him.  Senders remain free to use configuration,
heuristics, guessing, or whatever methods they like to decide when to
use PGP/MIME.

To be sure, this is a little odd since OpenPGP/MIME and OpenPGP are
two different things, and 2440bis is not the OpenPGP/MIME spec.
Nevertheless, since you can't do OpenPGP/MIME without OpenPGP, it
would be convenient to be able to advertise this capability via
OpenPGP.

Proposed text:
(Continue reading)

Permalink | Reply | 24 comments |
headers
Kazu Yamamoto | 15 Apr 2004 18:22

Re: "Yes, I can handle PGP/MIME"


From: David Shaw <dshaw <at> jabberwocky.com>
Subject: "Yes, I can handle PGP/MIME"

> Given all that, would there be some benefit in a standard way for a
> user to advertise that he can handle PGP/MIME?  Specifically, a
> "features" subpacket bit to say "I can handle PGP/MIME".

Interesting.

Bue I have a simple question:

Suppose Alice delivered her public key which says I can't handle
PGP/MIME. Then Alice comes to be able to handle PGP/MIME. How can she
deliver her (new) public key which says I can hadle PGP/MIME,
obsoleting old one?

--Kazu
Permalink | Reply | 1 comment |
headers
David Shaw | 15 Apr 2004 18:35

Re: "Yes, I can handle PGP/MIME"


On Fri, Apr 16, 2004 at 01:22:32AM +0900, Kazu Yamamoto wrote:
> From: David Shaw <dshaw <at> jabberwocky.com>
> Subject: "Yes, I can handle PGP/MIME"
> 
> > Given all that, would there be some benefit in a standard way for a
> > user to advertise that he can handle PGP/MIME?  Specifically, a
> > "features" subpacket bit to say "I can handle PGP/MIME".
> 
> Interesting.
> 
> Bue I have a simple question:
> 
> Suppose Alice delivered her public key which says I can't handle
> PGP/MIME. Then Alice comes to be able to handle PGP/MIME. How can she
> deliver her (new) public key which says I can hadle PGP/MIME,
> obsoleting old one?

The same way she handles it if she changes her OpenPGP program to one
that can handle MDC, or has different ciphers, or changes her
expiration date.  This is a standard thing in OpenPGP.  All of the
various informational subpackets can be rewritten if their information
changes.

Section 5.2.3.3 says:

    Since a self-signature contains important information about the
    key's use, an implementation SHOULD allow the user to rewrite the
    self-signature, and important information in it, such as
    preferences and key expiration.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Callas | 16 Apr 2004 00:21
Gravatar

Re: "Yes, I can handle PGP/MIME"


I have no problem with it. I'm a firm believer that we should be 
specifying syntax, and this is valuable syntax.

	Jon
Permalink | Reply | 0 comments |
headers
Adrian 'Dagurashibanipal' von Bidder | 16 Apr 2004 09:52
Picon

Re: "Yes, I can handle PGP/MIME"


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 15 April 2004 17.46, David Shaw wrote:

> Given all that, would there be some benefit in a standard way for a
> user to advertise that he can handle PGP/MIME?  Specifically, a
> "features" subpacket bit to say "I can handle PGP/MIME".

Since this is completely unrelated to OpenPGP itself, isn't this a good 
case for a notation packet on the selfsig? The big advantage is that 
this could be specified in the proper document - the one specifying 
PGP/MIME (well, when it is revised the next time), or in a document 
updating rfc3156.

I feel it is bad design to bloat the OpenPGP spec with application 
specific things like this (even when email is the dominant application 
of OpenPGP at this time.)

Notation 'pgp-mime=accept' or 'rfc3156=accept' or 'email=rfc3156' or ... 
(Hmmm. I like the latter - perhaps there will be other options on how 
email should be formatted etc., and it would allow 'email=clearsigned' 
if somebody wants to explicitly discourage PGP/MIME usage.)

greetings
- -- vbi

- -- 
featured link: http://fortytwo.ch/gpg/subkeys
(Continue reading)

Permalink | Reply | 1 comment |
headers
Will Price | 16 Apr 2004 11:24
Gravatar

Re: "Yes, I can handle PGP/MIME"


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the absence of a definitive non-advisory flag, we solved this 
problem over a year ago, and the solution is now deployed in many 
versions of shipping products. Since PGP products never (before PGP 
Universal) generated the preferred keyserver attribute on keys, we 
consider PGP/MIME to be a preferred encoding format if the recipient 
key has this flag. If the flag does not appear, we use Legacy encoding 
(to be distinguished from the simplistic "inline" encoding concept as 
real scenarios such as sending HTML, RTF, encoded multiparts, and 
attachments properly in a method compatible with legacy products 
requires far more work when not using PGP/MIME than simply encrypting a 
block of "inline" plaintext).

Given that most PGP products before PGP Universal did not support 
PGP/MIME, and the only extant keys with said flag were some GPG keys, 
and most GPG front ends both require and only support PGP/MIME, it was 
a logical choice which has worked out well.

Thus, we would have no use for such a flag (if you had posted your 
message two years ago, that would be a different answer). I don't 
anticipate any major email scenarios in the future which will not 
support at least the decoding of PGP/MIME. PGP products either do now 
or will use this flag in the way indicated above. Since most GPG front 
ends already require PGP/MIME and often set this flag on keys, the 
waters are already moving in the proper direction.

Email formats are becoming ever more complex. PGP/MIME is the only
(Continue reading)

Permalink | Reply | 18 comments |
headers
Adrian 'Dagurashibanipal' von Bidder | 16 Apr 2004 12:08
Picon

Re: "Yes, I can handle PGP/MIME"


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 16 April 2004 11.24, Will Price wrote:
[...]
> Email formats are becoming ever more complex. PGP/MIME is the only
> standard solution on the table.
[...] 

 - some people are not able to or do not want to use PGP/MIME for 
whatever reason
 - PGP/MIME might be replaced by yet another standard in the future.

I think, since userid are quite tightly bound to email addresses, that a 
way to tell the sender how the key owner expects to receive digitally 
signed/encrypted email is something that would solve an actual problem.

Remember, rfc1847 is now almost 10 years old, and rfc2015[*] is 8 years 
old, and still the dominant email client fails horribly on such 
messages, and still inline signed email is widely in use (you said that 
not many PGP product until recently supported PGP/MIME.) So I think 
being friendly to users of legacy solutions is one lession one should 
have learned by now in the IT world.

greetings
- -- vbi

[*] yes, I know the current standard is 3156, but I think the 
differencies do not matter for mailers *not* supporting that standard.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Len Sassaman | 16 Apr 2004 12:22

Re: "Yes, I can handle PGP/MIME"


On Fri, 16 Apr 2004, Will Price wrote:

> In the absence of a definitive non-advisory flag, we solved this
> problem over a year ago, and the solution is now deployed in many
> versions of shipping products. Since PGP products never (before PGP

For the record, I believe this "solution" to be ill-advised. Implementing
such hacks without discussion in this group will result in continued
compatibility issues between OpenPGP implementations.

I informed the product manager of PGP Universal of this error before the
product originally shipped, but was told it was too late to change tactics
at that point. Nevertheless, I still believe that the "preferred
keyserver" packet should indicate preferred keyservers, and that
MIME-encoding preferences should be indicated elsewhere.

Your solution is a hack, and an unnecessary one, since there is an elegant
means of expressing such information already built into OpenPGP -- the
notation data packet. I hope this is corrected in future releases of PGP
Universal.

--Len.
Permalink | Reply | 0 comments |

Gmane