Subject: Re: OpenPGP mail/news header -02

From: David Shaw <[email-masked]>
Date: Thu, 3 Nov 2005 11:21:44 -0500

On Mon, Oct 31, 2005 at 11:11:56AM +0100, Simon Josefsson wrote:
> 
> Hi everyone!  FYI:
> 
> I submitted an updated version of this document a few weeks ago.  The
> changes since -01 are small: A new "preference" field has been added,
> to signal whether the sender wish that e-mail should be signed,
> encrypted or both.

I have some concerns with this preference field.  There is already a
way to specify this preference on the key itself
("[email-masked]").  Once a user finds the key, they
have an authoritative and tamperproof statement about email
preference.  The OpenPGP header is not tamperproof, and having the
preference in there raises the question what to do if the header
preference doesn't match the preference on the key.

I see the OpenPGP header as a useful key finding aid.  Once the key is
found, though, the header has served its purpose.

David

---

From: "Brian G. Peterson" <[email-masked]>
Date: Thu, 3 Nov 2005 13:48:25 -0600

On Thursday 03 November 2005 10:21 am, David Shaw wrote:
> ("[email-masked]"). 

I'd like to see the preferred-email-encoding issue covered in an RFC or draft.  
I think that the issues around user preference and interoperability really 
need to be in an official RFC.  Hopefully we can take this up as 2440bis 
winds up and moves on into the next stages.

Regards,

   - Brian

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 04 Nov 2005 15:51:35 +0100

> ("[email-masked]").

That is not standardized though.  I agree with Brian that I'd like to
see it standardized.

> Once a user finds the key, they have an authoritative and
> tamperproof statement about email preference.  The OpenPGP header is
> not tamperproof, and having the preference in there raises the
> question what to do if the header preference doesn't match the
> preference on the key.

I hope the OpenPGP document doesn't leave any questions as to what
should happen.  The document says in several places that it is for
informational purposes, and that the information should not be
considered trust-worthy.

> found, though, the header has served its purpose.

I recall some situations where this preference field might be useful.
I think it was another way to bootstrap OpenPGP communication.

Yes, how about this use-case: An announcement-only mailing list might
prefer OpenPGP signed messages.  It could then add a 'OpenPGP:
preference=sign' message to all list posts.  The sender could be the
mailing list address, which may not have a OpenPGP key at all.  So you
couldn't fetch an OpenPGP key for the mailing list address.  Arguable,
the mailing list managers could create a dummy OpenPGP key for the
mailing list address, and set the e-mail preference and upload the
key.  However, so could anyone, since the key isn't used nor trusted
by anyone.  The announcement-only mailing list could be some abstract
mail addresses too.  Like [email-masked] or similar.

I haven't thought this idea through, so it may be silly.  However, I
recall convincing myself that the OpenPGP field may be useful in some
situations where a OpenPGP key preference field is less useful.  These
two ideas doesn't have to be mutually exclusive.  It is clear that the
tamper-proof preference should be preferred, if you trust that key,
but otherwise it doesn't matter.

Thanks,
Simon

---

From: David Shaw <[email-masked]>
Date: Fri, 4 Nov 2005 10:18:44 -0500

> winds up and moves on into the next stages.

I agree.  I think the current design is just fine, but documenting it
in an RFC is a good thing to do.

David

---

From: David Shaw <[email-masked]>
Date: Thu, 10 Nov 2005 10:34:21 -0500

On Fri, Nov 04, 2005 at 03:51:35PM +0100, Simon Josefsson wrote:

> Yes, how about this use-case: An announcement-only mailing list
> might prefer OpenPGP signed messages.  It could then add a 'OpenPGP:
> mailing list address, which may not have a OpenPGP key at all.  So
> you couldn't fetch an OpenPGP key for the mailing list address.
> Arguable, the mailing list managers could create a dummy OpenPGP key
> for the mailing list address, and set the e-mail preference and
> upload the key.  However, so could anyone, since the key isn't used
> nor trusted by anyone.  The announcement-only mailing list could be
> some abstract mail addresses too.  Like [email-masked] or
> similar.

I agree this is a reasonable use.  I've also re-read over the -02
draft, and it does have language in section 2 about not overtrusting
the header that I had missed earlier.

Would it be worth making this more explicit by adding something about
actual conflicts between the OpenPGP header and the key to that
section?  Something like:

  Some of the information given in this header may also be given on
  the OpenPGP key itself.  When these two sources conflict, users
  SHOULD favor the information from the OpenPGP key, as that information
  can be cryptographically protected.

David

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Nov 2005 17:32:40 +0100

> actual conflicts between the OpenPGP header and the key to that

Section 2 is intended to give an introduction, so I believe such text
should belong in the section that define the header.  It would be
useful to repeat the warning there as well.

I have added the following at the beginning of section 3:

      <t>Because the header is typically not integrity protected, the
	information conveyed in the OpenPGP header field MUST NOT be
	trusted without additional verification.  Some of the
	information given in this header may also be given on the
	OpenPGP key itself.  When these two sources conflict, users
	SHOULD favor the information from the OpenPGP key, as that
	information can be cryptographically protected.</t>

What do you think?

Thanks,
Simon