Subject: OpenPGP vs. OpenPGP/MIME

From: Jon Callas <[email-masked]>
Date: Thu, 24 Jan 2002 12:14:31 -0800

Let me state off the bat that I'm taking off any official hat as
author/editor/expert I might have. This is my personal opinion as a
computer user who uses OpenPGP.

I'm distressed by the opinion that I have heard (usually second or more
hand) that somehow base OpenPGP in 2440+ is deprecated, uncool, or
something, and that the way to go is OpnPGP/MIME. I think this is patently
ridiculous. Usually, the way to go is to use base OpenPGP, which for all
its flaws, has one major advantage over all other cryptosystems that I've
used, including OpenPGP/MIME. That advantage is this: It actually works.
Nearly never do I fail to decrypt, verify, etc. an OpenPGP object, and when
I do, the problem can be solved by ASCII armoring the output -- which means
that the problem is implicit line-end translation that damages the binary.

To repeat, this is not a philosophical objection. This is not because I
have some horrid dislike for MIME. Well, all right, I do have a horrid
dislike for MIME, but I have a horrid dislike for MIME solely because it
doesn't work. I'm a practical person. I like any and all technologies that
work without my fussing with them. If we waved a magic wand and these
things started working, I wouldn't object. I would even start says, "Hey,
MIME actually works." But they don't work, and I do dislike them for this
lack.

MIME does one thing well -- putting in files as attachments, and thus
making email a convenient file transfer protocol. This almost always works.
The further one strays from this basic function, the less reliable it is.
Sending a message in HTML and MIME-attaching pictures works pretty
reliably. But by the time you get to doing security multiparts,
interoperability mostly sucks. With OpenPGP/MIME, this is particularly
frustrating because there is almost always a perfectly good way to do the
same thing without MIME that would have worked fine.

Using OpenPGP/MIME makes sense when:

(1) The operation you were going to do needed to use MIME anyway. For
example, you're sending someone an attachment, and you'd like it encrypted.

(2) You're using some feature of OpenPGP/MIME that gives you useful things
you can't get any other way. Parallel signatures spring to mind.

Using OpenPGP/MIME makes no sense when:

(1) Whatever you were doing does little take the "-----BEGIN PGP
MESSAGE-----" header and prefix it with one that says, "Content type:
application/whatever".

(2) Protecting a blob of data has nothing whatsoever to do with MIME. For
example, I know of a banking system that uses OpenPGP encoded messages.
There's no need for MIME here.

MIME-coded messages have great uses. But alas, even to this day, there are
lots of uses of them that aren't quite ready for prime time. Let's face it
-- the majority of mailers don't do MIME correctly, and if I have to pry
apart attachments to get to a clearsigned signature just so I can
re-assemble the thing in a text editor so I can check the signature, I'm
probably not going to do it. It had better be pretty important for me to
take five minutes out of my day to bother. If it's encrypted, it's a lot
easier for me to decide that the message is more akin to the last chance
offers for domain names, offers to buy drugs without prescriptions, and
entreaties to skim off some subsarharan money that I get, and treat the
message the same way.

	Jon

---

From: David Shaw <[email-masked]>
Date: Thu, 24 Jan 2002 16:45:34 -0500

On Thu, Jan 24, 2002 at 12:14:31PM -0800, Jon Callas wrote:
> something, and that the way to go is OpnPGP/MIME.

I think at least some of those opinions are based on section 2.4 in
2440bis:

   Note that many applications, particularly messaging applications,
   will want more advanced features as described in the OpenPGP-MIME
   document, RFC2015. An application that implements OpenPGP for
   messaging SHOULD implement OpenPGP-MIME.

Statements like "many applications, ... will want more advanced..",
and "SHOULD" imply (to my eye) "This is what I should use.  The other
way must not be as good, or the RFC wouldn't have told me I SHOULD use
this."

> probably not going to do it.

I actually like PGP/MIME quite a lot - it handles painlessly a lot of
fussy details that otherwise I'd have to handle.

I stopped using it when I found myself in a corporate environment
where the majority of people were using various corporate mailers that
blew up in various odd ways with it.  I'm sure this isn't a PGP/MIME
thing - they'd have blown up with any MIME they didn't understand, but
while a regular clearsigned signature can be ignored by those people
that either don't care or don't use PGP, a PGP/MIME message does not
always degrade quite so gracefully.

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Jan 2002 23:38:13 +0100

> always degrade quite so gracefully.

I think you just pretty well described what Jon meant by PGP/MIME
often not working in practice, whereas OpenPGP usually does work.

I agree with Jon's opinion.  PGP/MIME interoperability is bad.  I
believe it is the design of RFC 1847 that makes interoperability low.
I'm even considering arguing for the solution chosen by Outlook PGP
plugins when it comes to PGP and MIME, just PGP encrypt each MIME part
without touching the MIME headers at all.  That solution _works_, even
though it is ugly and bad and wrong from a engineering point of view.

---

From: Thomas Roessler <[email-masked]>
Date: Thu, 24 Jan 2002 23:46:03 +0100

On 2002-01-24 23:38:13 +0100, Simon Josefsson wrote:

>I agree with Jon's opinion.  PGP/MIME interoperability is bad.  

Really?  It certainly won't get worse than MIME interoperability in 
general.

>I believe it is the design of RFC 1847 that makes interoperability 
>low. I'm even considering arguing for the solution chosen by 
>Outlook PGP plugins when it comes to PGP and MIME, just PGP 
>encrypt each MIME part without touching the MIME headers at all. 

Funny enough, S/MIME uses RFC 1847 as well, and that one works.

-- 
Thomas Roessler                        <[email-masked]>

---

From: Jon Callas <[email-masked]>
Date: Thu, 24 Jan 2002 16:48:32 -0800

>Really?  It certainly won't get worse than MIME interoperability in

That is precisely my point. It's not a PGP problem, it's a MIME problem.
Which means that PGP/MIME is a good thing in theory, but not in practice.
Once MIME interoperability starts working, more power to it.

>Funny enough, S/MIME uses RFC 1847 as well, and that one works.

Funny enough, not I nor anyone I know has ever used S/MIME successfully.
But I suspect that is cultural more than technical.

	Jon

---

From: James M Galvin <[email-masked]>
Date: Thu, 24 Jan 2002 20:17:12 -0500 (EST)

On Thu, 24 Jan 2002, Simon Josefsson wrote:

    I
    believe it is the design of RFC 1847 that makes interoperability
    low.

In what way?  Please explain.

Jim
co-Author of RFC1847 (for which a revision is in progress)

--
James M. Galvin <[email-masked]>

---

From: David Shaw <[email-masked]>
Date: Thu, 24 Jan 2002 20:22:28 -0500

> often not working in practice, whereas OpenPGP usually does work.

Exactly.  I was agreeing with Jon as well (did I accidentally say
OpenPGP somewhere where I meant PGP/MIME or vice versa?)

In my experience, MIME in general except for two cases too frequently
does "interesting" things.  Those two good cases are a) the really
common stuff (attaching a file and forwarding an email, possibly with
its own attachments), and b) the stuff the vendor provides, and
therefore tests (S/MIME, etc.)

David

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 25 Jan 2002 21:25:37 +0900 (JST)

From: James M Galvin <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME

> In what way?  Please explain.

I think RFC 1847 has several ambiguities:

(1) It's not clear whether or not the protocol parameter is
    case-sensitive. The parameter indicates content type, which is
    case-insensitive, of a second part. However, the parameter is
    case-sensitive because RFC 1847 does not mention this explicitly.

(2) It's not clear how a receiving MUA should do when the value of the
    protocol parameter is different from the value of content type (of
    the first part for encryption and of the second part for
    signature.)

(3) It's not clear how a receiving MUA should do when the value of
    the micalg parameter is differnt from the value specified in the
    second part(e.g a PGP packet for PGP/MIME).

> co-Author of RFC1847 (for which a revision is in progress)

Good news. Where can I find the draft?

--Kazu

---

From: Werner Koch <[email-masked]>
Date: Fri, 25 Jan 2002 14:15:06 +0100

>     the first part for encryption and of the second part for

How an error is handled is not in the scope of most protocols.  Do
whatever you see fits.  Issue a warning so that such errors don't get
unnoticed.

>     second part(e.g a PGP packet for PGP/MIME).

For PGP just ignore it.  It does not make sense because you can't just
feed the hash into a OpenPGP verifier (there are other informations
needed to be hashed along with the message).  Well, unless you want to
have a big monolithic application which can pass hash contexts around.

 Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 25 Jan 2002 14:09:54 +0100

> Really?  It certainly won't get worse than MIME interoperability in

MIME interop isn't very good, when you beyond the simple features.  As
an example, my mail server filter multipart/signed.  I have no idea
why, and of course it is a bug, but the point is that for some reason
the deployment of PGP/MIME failed here.

>> low. I'm even considering arguing for the solution chosen by Outlook
>> PGP plugins when it comes to PGP and MIME, just PGP encrypt each
>> MIME part without touching the MIME headers at all.
>

S/MIME doesn't use RFC 1847 for encrypting messages, and S/MIME allows
non-RFC 1847 mechanisms when it comes to signed messages as well.

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 25 Jan 2002 22:53:37 +0900 (JST)

From: Werner Koch <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME

> whatever you see fits.

I understand what you mean. And I agree with you in many cases. 

However, RFC 1847 is to define a signature service. If error handing
is implementation dependent, a broken multipart/security is verified
as GOOD in some MUAs and it is verified as BAD in other MUAs. This is
not good for signature services.

> have a big monolithic application which can pass hash contexts around.

So, why is the micalg parameter a MUST?

--Kazu

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 25 Jan 2002 14:57:11 +0100

> In what way?  Please explain.

Here are some of my issues with RFC 1847.  I'm not sure a simple
revision of RFC 1847 can fix them, but I hope this is of some use
during the revision of the document at least.  Some of these aren't
really technical arguments, but rather rooted in implementation and
operational experience.

* Assumes that MIME delimiters are immutable.

  In practice, MIME delimiters are changed in transit.  I haven't
  found anything that explicitly forbids this in MIME, and the design
  of MIME sort of suggests that decoding and re-encoding the document
  is OK.  Some IMAP servers are designed around this assumption, and I
  can't say that I blame them.

* RFC 1847 assumes that applications have access to the raw
  transmitted MIME blob, rather than a MIME decoded object.  Some mail
  access protocols, such as IMAP, can decode and split structured MIME
  objects.

* It does not say that multipart/{signed,encrypted} parts (including
  MIME delimiters) MUST be preserved as-is when MUAs forward them
  using e.g. message/rfc822.  Perhaps it is the odd one out, but the
  "forward" function in Gnus decodes MIME messages by default, to be
  able to display them properly in the message editing buffer, and
  later re-encodes the message.  

* Not the fault of RFC 1847, but some MIME applications does not
  follow the MIME recommendation to treat unknown multipart/foo types
  as multipart/mixed.  So the parts are trashed, filtered, or marked
  as "viruses" or something.  This is a implementation problem, but if
  a protocol can make implementation problems less likely to happen,
  this should be considered in the design of the protocol IMHO.

* The MICALG parameter should be made optional.  For some security
  infrastructures, it isn't applicable.  For OpenPGP, it is not clear
  if the MICALG or the field inside the PGP signature blob should be
  used. Some mailers (Mutt) have been sending MD5 in the MICALG field
  and MIC:ing the message with SHA1.

Perhaps illustrating is to consider an alternative approach of
marrying mail security and MIME:

  The MIME structure is left as-is, and the body part is altered to
  include a "security" blob.

This path is chosen by some Outlook PGP plugins (surely because the
Outlook API is limited, and not by design, I am sure), and in my
experience it works better than PGP/MIME -- legacy applications
doesn't destroy the security blob and MIME aware message protocols are
able to to retrieve just one MIME part and have it be
verified/decrypted, everything else being equal.  This solution is
probably a bit against the spirit of MIME (the Content-Type header
should be the sole specifier of how to treat a MIME body), so I'm not
seriously advocating it as a standard, but it could be useful to
compare the two approaches.  One way to make this somewhat more MIME
friendly would to add a MIME Content-Type parameter "signed=pgp" on a
part that has undergone PGP treatment (and leaving the Content-Type to
text/plain, application/msword etc as is).

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 25 Jan 2002 15:07:21 +0100

Werner Koch <[email-masked]> writes:

> needed to be hashed along with the message).

This view isn't consistent with how I read RFC 3156, it seems to
require that applications populate the field with the MIC algorithm
used to hash the message.  Using the wrong micalg value causes
problems.

IMHO either the micalg parameter should be made optional, or the
PGP/MIME spec should suggest using a dummy value ("micalg=pgp") to
signal to the application that the algorithm specified in the OpenPGP
blob should be used.

---

From: Derek Atkins <[email-masked]>
Date: 25 Jan 2002 12:55:04 -0500

The point behind the micalg= parameter was for ease in implementation
of a one-pass processing.  If you know in advance to setup an md5
or sha1 hash processor, you can process the message through the hash
before you get to the signature portion.

At least that was why it was done originally,

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Sat, 26 Jan 2002 04:20:16 +0900 (JST)

From: Derek Atkins <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME

> before you get to the signature portion.

I know. But who is using this feature actually?

--Kazu

---

From: Derek Atkins <[email-masked]>
Date: 25 Jan 2002 15:38:38 -0500

I dont know.  I suspect that an integrated MIME parser with the
PGPsdk _could_ use it, but I don't know if anyone does.

-derek

---

From: Werner Koch <[email-masked]>
Date: Sat, 26 Jan 2002 11:38:11 +0100

> I know. But who is using this feature actually?

For S/MIME it does really make sense as you don't need to pass a
lengthly message to the S/MIME application.  You can just pass the
hash value.  This is different from OpenPGP because S/MIME uses a
2-stage hashing method (in most cases).

  Werner

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 28 Jan 2002 20:08:37 +0900 (JST)

Werner

> 2-stage hashing method (in most cases).

I don't understand this. I think you are talking about verification,
not creating a signature.

Would you tell me how the micalg parameter is useful for S/MIME
application on verification more concretely? Probably I should
understand what 2-stage hashing method is.

--Kazu

---

From: Werner Koch <[email-masked]>
Date: Mon, 28 Jan 2002 13:07:56 +0100

> not creating a signature.

Right.  When you create a signature, you know in advance what hash
algorithm to use.

> understand what 2-stage hashing method is.

S/MIME usually hashes the text and store the hash value inside the so
called signedAttributes.  The signedAttributes, which are usually
small and contain various things like the signature creation time, are
then hashed again and that value is the input to the PK verification
algorithm.

OpenPGP hashes everything as one big block.  The problem is that you
can't feed the hash value to OpenPGP because it is not possible to
hash more stuff after a hash as been finalized (i.e. the hash value
calculated) - well it would be possible to use the intermediate values
(the hash context) to the verification process, so that it can hash
more data in, but I don't consider this a clean design.

  Werner

To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 28 Jan 2002 13:07:56 +0100
Lines: 31
Sender: [email-masked]

> not creating a signature.

Right.  When you create a signature, you know in advance what hash
algorithm to use.

> understand what 2-stage hashing method is.

S/MIME usually hashes the text and store the hash value inside the so
called signedAttributes.  The signedAttributes, which are usually
small and contain various things like the signature creation time, are
then hashed again and that value is the input to the PK verification
algorithm.

OpenPGP hashes everything as one big block.  The problem is that you
can't feed the hash value to OpenPGP because it is not possible to
hash more stuff after a hash as been finalized (i.e. the hash value
calculated) - well it would be possible to use the intermediate values
(the hash context) to the verification process, so that it can hash
more data in, but I don't consider this a clean design.

  Werner

Date: Mon, 28 Jan 2002 20:08:37 +0900 (JST)
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

Werner

--Kazu

Subject: Need help - public and private keys in OpenPGP format
content-class: urn:content-classes:message
Date: Mon, 28 Jan 2002 12:36:48 +0200
From: "Cornel GLIGAN" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi!
I want to store a public key and a private key in OpenPGP format. Is
there anyone who can give me some examples, or who can tell me where can
I find some examples with this topic? (I work with Visual C++ 6.0 and
Windows 2000)
Tank you in advance,
Cornel Gligan-Ignatescu

To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Sat, 26 Jan 2002 11:38:11 +0100
Lines: 15
Sender: [email-masked]

  Werner

To: Kazu Yamamoto (=?iso-2022-jp?b?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Derek Atkins <[email-masked]>
Date: 25 Jan 2002 15:38:38 -0500
Lines: 24
Sender: [email-masked]

-derek

Date: Sat, 26 Jan 2002 04:20:16 +0900 (JST)
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

--Kazu

To: Simon Josefsson <[email-masked]>
Cc: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Derek Atkins <[email-masked]>
Date: 25 Jan 2002 12:55:04 -0500
Lines: 36
Sender: [email-masked]

-derek

Subject: Re: OpenPGP vs. OpenPGP/MIME
To: [email-masked]
From: [email-masked]
Date: Fri, 25 Jan 2002 11:07:24 -0600
Sender: [email-masked]

From: John Dlugosz

Re compatibility: I use (don't laugh) Lotus Notes 4.5 at work, and it is
totally different from normal email.  It has a gateway to translate
internet mail into its own document format.

Mime attachments are turned into embedded documents at the end.

What would it do to PGP/MIME or any other use of MIME that requires knowing
the =meaning= of the parts?  I doubt it would work.

Regular old-fashond ASCII Armored PGP works fine.  With the GUI tools from
NAI, it's pretty simple to use via the clipboard even though L.N. is
totally unaware of it.

If the main point of PGP/MIME was to get mail readers to transparantly
handle PGP, it obviously has problems for readers that =don't=.  And mail
readers could just as easily be built to know about the ===BEGIN...===
lines.

Just to throw something out, how about ASCII-Armored PGP for the body of
the message, and MIME attachments for multiple (paralell) signatures?  For
that matter, they wouldn't need MIME, just another ASCII Armor'ed block
following the main one.

--John

Subject: Please help me! I'm new with OpenPGP
content-class: urn:content-classes:message
Date: Fri, 25 Jan 2002 16:22:04 +0200
From: "Cornel GLIGAN" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi!

I'm new in OpenPGP domain. First of all I would like to know if tis
mailing list is still functionally because the last message was posted
in 18 Jan 2000.

Thank you in advance,

Cornel Gligan-Ignatescu

From: Simon Josefsson <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Date: Fri, 25 Jan 2002 15:07:21 +0100
Lines: 19
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: James M Galvin <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Date: Fri, 25 Jan 2002 14:57:11 +0100
Lines: 65
Sender: [email-masked]

Date: Fri, 25 Jan 2002 22:53:37 +0900 (JST)
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

--Kazu

To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 25 Jan 2002 14:15:06 +0100
Lines: 25
Sender: [email-masked]

 Werner

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Date: Fri, 25 Jan 2002 14:09:54 +0100
Lines: 21
Sender: [email-masked]

Date: Fri, 25 Jan 2002 21:25:37 +0900 (JST)
To: [email-masked], [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

--Kazu

Date: Thu, 24 Jan 2002 20:22:28 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Date: Thu, 24 Jan 2002 20:17:12 -0500 (EST)
From: James M Galvin <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

    I

Jim

Date: Thu, 24 Jan 2002 16:48:32 -0800
To: Thomas Roessler <[email-masked]>, Simon Josefsson <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME
Cc: [email-masked]
Sender: [email-masked]

	Jon

Date: Thu, 24 Jan 2002 23:46:03 +0100
From: Thomas Roessler <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Jan 2002 23:38:13 +0100
Lines: 19
Sender: [email-masked]

Date: Thu, 24 Jan 2002 16:45:34 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Date: Thu, 24 Jan 2002 12:14:31 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: OpenPGP vs. OpenPGP/MIME
Sender: [email-masked]

	Jon

Date: Sat, 19 Jan 2002 15:09:47 +0200
From: Nikos Mavroyanopoulos <[email-masked]>
To: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
Sender: [email-masked]

On Fri, 18 Jan 2002 16:18:46 +0200 Nikos Mavroyanopoulos <[email-masked]> wrote:

> > That is also my understanding.  The point is whether it is possible
> > lookup a key based on the fingerprint.  I say yes because for a local
> > lookup you should index you keyring anyway (think about a server and
> > millions of users) and then it doesn't matter whether to lookup by
> > fingerprint or keyID. 
[...]
> The reason I replaced keyIDs with Fingerprints is that this identifier
> is covered by the TLS Finished messages. This means that after the Finished 
> messages are sent, the parties know that the peer got a key which is identified 
> by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify 
> for this. If they should be added, they should be added for backwards 
> compatibility and only for this reason.

On second thoughts, I think there is not an issue for backwards compatibility,
since a client is not required to send the fingerprint (he may send the key).
A holder of a v3 key may send the key instead of the fingerprint, in the
case he suspects that the server could not retrieve the key.

I think this is the most clean solution. If you agree I'll keep the original
version.

-- 
Nikos Mavroyanopoulos
mailto:[email-masked]

Date: Fri, 18 Jan 2002 16:18:46 +0200
From: Nikos Mavroyanopoulos <[email-masked]>
To: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
Sender: [email-masked]

On Thu, 17 Jan 2002 20:04:28 +0100 Werner Koch <[email-masked]> wrote:

> > used to present an "I can use this key" message to the other side,
> > which implies (to me) that the remote end would need to lookup a key
> > based on that number.  Could you please explain how this "identifier"
> That is also my understanding.  The point is whether it is possible
> lookup a key based on the fingerprint.  I say yes because for a local
> lookup you should index you keyring anyway (think about a server and
> millions of users) and then it doesn't matter whether to lookup by
> fingerprint or keyID. 

I should add here that:

This identifier is used with 2 purposes:
1. To identify the key 
2. To provide equal security with the case where the actual key is sent [0]

The reason I replaced keyIDs with Fingerprints is that this identifier
is covered by the TLS Finished messages. This means that after the Finished 
messages are sent, the parties know that the peer got a key which is identified 
by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify 
for this. If they should be added, they should be added for backwards 
compatibility and only for this reason.

[0]: This is also discussed in the draft-ietf-tls-extensions-02 in the
 security considerations chapter (client certificate URL extension).
[1]: I don't believe that a hash truncated to 64bits provides any security

-- 
Nikos Mavroyanopoulos
mailto:[email-masked]

To: [email-masked], [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 18 Jan 2002 12:54:19 +0100
Lines: 53
Sender: [email-masked]

[I am not on the tls list, feel free to resend it]

On Thu, 17 Jan 2002 16:39:20 -0800, Will Price said:

> Another important point about backwards compatibility: the current
> OpenPGP/TLS draft already has well over a million deployed clients.

This is an expired draft and as such not anymore accessible.

And:

   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

> Every PGP client since I believe 6.0.0 (September 1998) supports
> PGPtls as described in the draft, and every PGP Keyserver since that

PGP has a lot of proprietary features which are either in conflict to
OpenPGP or not documented at all.  NAI folks are talking for years:
"We will write up the specification RSN" - I have never seen more than
these announcements.  Some non-NAI folks reverse engineered the format
of the photo ID from actual PGP output, so that David Shaw could
implement this in GnuPG but most other stuff is unknown and NAI is
even dropping OpenPGP required features (v4 sigs on data) - well may
be this is a bug, but those things have happened far too often.

> While PGPtls in the PGPsdk was the first implementation (for which
> source code is currently available at the pgp website, and part of
> every source release we've done for the last few years), I know

And since you re-opened the source for >= 7, you use a license which
makes the source useless and actual dangerous for a programmer to look
at. 

> In addition to ignoring all the fielded uses and implementations of
> OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency

There is no documentation on this format - may be PGP implemented that
draft but nobody writing TLS or OpenPGP code is able to even check
this as there is no usable source.

If NAI would have been interested in standard conformace, the draft
should be reissued regulary and the extensions to OpenPGP discussed
with the OpenPGP WG.  The same thing goes for OpenPGP features like
MDC and a new transport format for secret keys - NAI seems not to be
interested in it anymore.

  Werner

Date: Fri, 18 Jan 2002 10:41:23 +0200
From: [email-masked]
Organization: disastry.NO.SPaM.NET
To: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
Sender: [email-masked]

Werner Koch wrote:

> On 17 Jan 2002 09:52:24 -0500, Derek Atkins said:
> 
> > You probably do not want to assume that the fingerprint is 20 octets
> > long; fingerprints on v3 RSA keys are only 16 octets long.  So, your
> 
> Left pad them with zeroes and store the fingerprint

maybe right pad fingerprint with keyid.
but there is only space for short 4byte keyid..

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

Date: Thu, 17 Jan 2002 21:11:01 -0800
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: IETF Transport Layer Security WG <[email-masked]>
CC: [email-masked]
Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls
Sender: [email-masked]

Eric Rescorla wrote:
> Will Price <[email-masked]> writes:
> > History shows that is not actually true. For instance, TLS is
> > almost identical to SSL. Why is this? Is it because
> > "implementation
> > experience" showed that SSL was simply the One True Way to write
> > a transport security protocol? No. It's because there was a large
> > SSL installed base of which the TLS designers wanted to take
> > advantage, and thus the more identical the protocol was the more
> > it would be accepted.
> Funny, I think of the TLS experience the opposite way: Despite
> the fact that SSL had an enormous installed base TLS is
> incompatible with SSL.
> 
> > - From an implementation experience point of view, I would say
> > that the last four years have demonstrated the cipher suite space
> > issue is not an issue, and the "we're going to run out of space"
> > argument is the only one made to defend this negotiation proposal
> > which depends on an extension proposal.
> No. Even in the absence of the cipher suite depletion argument,
> your approach would be a clumsy hack. Orthogonality is a good
> thing.

Orthogonality?  Like the orthogonality of lumping the cipher type,
key length, hash type, key exchange type, and export status into one
sixteen bit number?  I don't think so. Sorry, that argument doesn't
fly in the context of TLS. The Orthogonality to the Nth degree
doorway is in the IPsec WG.

For TLS 1.0, the cipher suite remains the right place to put this.
What we wanted in 1998, and what we still want today is a TLS 1.1
which has a field for the certificate type.

I think we both agree in principle that certificate type should have
had its own field. The difference is that you're willing ditch
backwards compatibility and change OpenPGP/TLS to include its own
clumsy hack for specifying the certificate type and depend on yet
another draft, whereas we've done things the TLS 1.0 way in TLS 1.0
and would support fixing the protocol itself in a future rev.

- -- Will

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

Date: Thu, 17 Jan 2002 20:11:51 -0800
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: IETF Transport Layer Security WG <[email-masked]>
CC: [email-masked]
Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls
Sender: [email-masked]

History shows that is not actually true. For instance, TLS is almost
identical to SSL. Why is this? Is it because "implementation
experience" showed that SSL was simply the One True Way to write a
transport security protocol? No. It's because there was a large SSL
installed base of which the TLS designers wanted to take advantage,
and thus the more identical the protocol was the more it would be
accepted.

- From an implementation experience point of view, I would say that the
last four years have demonstrated the cipher suite space issue is not
an issue, and the "we're going to run out of space" argument is the
only one made to defend this negotiation proposal which depends on an
extension proposal. Time has demonstrated that particular sky is not
going to fall, and thus in the absence of any method in the standard
to specify certificate type the cipher suite field remains the
correct place to put this.

Eric Rescorla wrote:
> Implementation experience is an important factor. The existence of
> implementations which were written pre-Proposed and which would be
> broken by a new specification isn't. If you want to argue that your
> implementation experience indicates that this is the right approach
> and some other approach is wrong, go ahead. I don't see you arguing
> that. Rather, I see you arguing that you (and presumably others)
> have implemented a specific approach and would be inconvenienced by
> any other approach, regardless of its technical merits. That's not
> the basis on which the IETF is supposed to make decisions.

- -- Will

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

Date: Thu, 17 Jan 2002 19:00:56 -0800
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: IETF Transport Layer Security WG <[email-masked]>
CC: [email-masked]
Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls
Sender: [email-masked]

Eric Rescorla wrote:
> Will Price <[email-masked]> writes:
> > Another important point about backwards compatibility: the
> > current OpenPGP/TLS draft already has well over a million
> > deployed clients. Every PGP client since I believe 6.0.0
> > (September 1998) supports PGPtls as described in the draft, and
> > every PGP Keyserver since that time period also supports PGPtls.
> I don't find this argument very convincing. You implement things
> that are Internet-Drafts at your own risk. That's why every I-D
> has a disclaimer at the top. If popularity were the criterion
> for standardization, we could disband the IETF and just wait
> for Microsoft to tell us what the standard was.

We published the draft, then we implemented, then we published code.
This is standard procedure for anybody in the IETF. Implementations
and implementation experience are critical factors in the WG, and if
they could be ignored then TLS/SSL would be quite different today I'm
sure you'll admit.

> > In addition to ignoring all the fielded uses and implementations
> > of OpenPGP/TLS, Nikos' proposed changes also suffer from the
> > dependency problem on the TLSEXT draft,
> This is a feature not a bug.

Definitely seems like a bug to me. When I originally designed this,
it was clear that TLS should have had a standard way of choosing a
certificate type much like IKE does. I believe I raised this issue on
the list at the time and the response of the list was IIRC muted
agreement, but there were no plans for a new version of the TLS draft
so it wasn't a discussion that was going to go anywhere. The others I
spoke with in the WG felt that using the cipher suite field was the
way to go.

Writing a draft for a new certificate type which defines an impromptu
technique for how to negotiate an OpenPGP certificate type is clearly
not the way to go. TLS should always have had a certificate type
field built-in. Were TLS to have such a standardized method, the
OpenPGP/TLS draft should be modified to adopt that.

However, it's not particularly important that such a method be
developed. No more than 2 perhaps 3 certificate types will survive
into the future, so that doesn't appear to be a serious concern.
Worrying about running out of 16 bit space for cipher suites is
unnecessary to me. We should now and should always have been
conservative about which cipher suites get assigned numbers. No more
than 20 cipher suites are in active use today, and going forward into
the future I expect those to change but the overall number of
actively used cipher suites will get smaller converging on the
popular few.

- -- Will

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

Date: Thu, 17 Jan 2002 16:39:20 -0800
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
Sender: [email-masked]

Another important point about backwards compatibility: the current
OpenPGP/TLS draft already has well over a million deployed clients.
Every PGP client since I believe 6.0.0 (September 1998) supports
PGPtls as described in the draft, and every PGP Keyserver since that
time period also supports PGPtls.

PGPtls can be used for split key network reconstitution, normal key
searches on keyservers, client authentication to keyservers for the
purpose of deleting or disabling keys, and a whole host of other
things in various products from NAI and others.

While PGPtls in the PGPsdk was the first implementation (for which
source code is currently available at the pgp website, and part of
every source release we've done for the last few years), I know
others have mentioned other implementations as well to me over the
last year or so.

In addition to ignoring all the fielded uses and implementations of
OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency
problem on the TLSEXT draft, and the Fingerprint/KeyID confusion
which I've previously detailed on the ietf-tls list. It would be a
huge mistake to adopt the proposed changes.

Derek Atkins wrote:
> >   Let's avoid the X.509
> > problem of not knowing how to cleany identify a key.
> 
> Why not add 8 more bytes and you still get this functionality and
> backwards compatibility?
> 
> Keep in mind that lack-of-backwards-compatibility is what got us
> where we are today, a fragmented community of people.  It all
> started with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP.
> 
> Backwards compatibility is a Good Thing, in particular when talking
> about long-lived identity keys.

- - -- 

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 14:52:09 -0500
Lines: 21
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

>   Let's avoid the X.509
> problem of not knowing how to cleany identify a key.

Why not add 8 more bytes and you still get this functionality and
backwards compatibility?

Keep in mind that lack-of-backwards-compatibility is what got us
where we are today, a fragmented community of people.  It all started
with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP.

Backwards compatibility is a Good Thing, in particular when talking
about long-lived identity keys.

-derek

To: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 17 Jan 2002 20:04:28 +0100
Lines: 34
Sender: [email-masked]

On 17 Jan 2002 13:07:43 -0500, Derek Atkins said:

> used to present an "I can use this key" message to the other side,
> which implies (to me) that the remote end would need to lookup a key
> based on that number.  Could you please explain how this "identifier"

That is also my understanding.  The point is whether it is possible
lookup a key based on the fingerprint.  I say yes because for a local
lookup you should index you keyring anyway (think about a server and
millions of users) and then it doesn't matter whether to lookup by
fingerprint or keyID.  There is even no reasonable high overhead when
inserting a new key: Most keys are v4 and to get a keyID you need to
calculate the fingerprint anyway.  For the few v3 keys (cf. dtype.org
for keyserver statistics) you can avoid the fingerprint calculation
but really this doesn't matter anymore.

For a lookup via keyserver there is probably a problem with the HKS
type servers but they have so many problems that they have to replaced
anyway.  I am pretty sure that the NAI certserver is able to do a
lookup by fingerprint and to add this to the ALMI and cryptnet servers
will only take a few hours.

So why not using _only_ the fingerprint in TLS.  IIRC we had a
discussion a long time ago to allow the use of fingerprint in the next
version of signature packets.  My point is that the fingerprint is the
correct way to identify a key and that there is no need for backward
compatibilty when a new protocol is designed.  Let's avoid the X.509
problem of not knowing how to cleany identify a key.

To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 13:07:43 -0500
Lines: 30
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> On 17 Jan 2002 12:44:30 -0500, Derek Atkins said:
> 
> > Keep in mind that TLS can use "user certificates" too... Are you
> > implying that users with v3 certs have to generate a new key
> > in order to use them in TLS?
> 
> Yes, for the same reasons as for servers.  The majority of keys is v4

I disagree that these reasons are valid... But that's not important
right now..

> And I still don't see a reason why a keyID is needed in TLS.  We need
> the keyIDs to lookup signing keys but this has nothing to do with TLS.

Ok, perhaps I am confused.  Could you please explain how the
fingerprint would get used the TLS protocol?  I thought it was being
used to present an "I can use this key" message to the other side,
which implies (to me) that the remote end would need to lookup a key
based on that number.  Could you please explain how this "identifier"
is meant to be used within TLS?

-derek

To: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 17 Jan 2002 19:01:20 +0100
Lines: 17
Sender: [email-masked]

On 17 Jan 2002 12:44:30 -0500, Derek Atkins said:

> Keep in mind that TLS can use "user certificates" too... Are you
> implying that users with v3 certs have to generate a new key
> in order to use them in TLS?

Yes, for the same reasons as for servers.  The majority of keys is v4
for quite a long time now.  I know only a few people insisting on
using the old keys - even Ted T'so has a v4 key now.

And I still don't see a reason why a keyID is needed in TLS.  We need
the keyIDs to lookup signing keys but this has nothing to do with TLS.

To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 12:44:30 -0500
Lines: 43
Sender: [email-masked]

Keep in mind that TLS can use "user certificates" too... Are you
implying that users with v3 certs have to generate a new key
in order to use them in TLS?

-derek

Werner Koch <[email-masked]> writes:

> On 17 Jan 2002 12:24:03 -0500, Derek Atkins said:
> 
> > I don't think that's a reasonable assumption to make.  Worse, if you
> > have _ANY_ v3 keys then you need to ship the keyID.  Perhaps there is
> 
> Why?  Because the HKP keyservers are not able to search by
> fingerprint?  Hopefully this will be fixed and the modern key servers
> support such a lookup (well, not checked but easy to add).
> 
> I can't imagine that anyone will use an old v3 key for TLS
> authentication - TLS is always used on a networked machine (surprise)
> and as such this machine is much more exposed to attacks than the
> secure boxes we all use to handle or secret keys ;-).  If TLS is
> configured somewhere, a new key should be used for this and this key
> can in turn be signed by certification key.
> 
> Using PGP keys with TLS is a new thing and we don't have to take
> backwards compatibility into account.
> 
> Ciao,
> 
>   Werner
> 
> 
> -- 

To: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 17 Jan 2002 18:33:24 +0100
Lines: 28
Sender: [email-masked]

On 17 Jan 2002 12:24:03 -0500, Derek Atkins said:

> I don't think that's a reasonable assumption to make.  Worse, if you
> have _ANY_ v3 keys then you need to ship the keyID.  Perhaps there is

Why?  Because the HKP keyservers are not able to search by
fingerprint?  Hopefully this will be fixed and the modern key servers
support such a lookup (well, not checked but easy to add).

I can't imagine that anyone will use an old v3 key for TLS
authentication - TLS is always used on a networked machine (surprise)
and as such this machine is much more exposed to attacks than the
secure boxes we all use to handle or secret keys ;-).  If TLS is
configured somewhere, a new key should be used for this and this key
can in turn be signed by certification key.

Using PGP keys with TLS is a new thing and we don't have to take
backwards compatibility into account.

Ciao,

  Werner

To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 12:24:03 -0500
Lines: 30
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> > You probably want to send along the keyID as well as the fingerprint.
> 
> Frankly, I suggested to drop the keyID because the few extra bytes for
> a fingerprint are not an issue and it makes the code easier if we only
> have to lookup by fingerprint.

Sure, it's redundant for v4 keys but it's required for v3 keys.

> > Most implementations can only lookup a key based on the keyID.  As a
> 
> Then they should be fixed. To lookup by keyID you have to calculate
> the fingerprint anyway for v4 keys.  And there won't be many v3 keys
> in use with TLS.

I don't think that's a reasonable assumption to make.  Worse, if you
have _ANY_ v3 keys then you need to ship the keyID.  Perhaps there is
some way that if keyID == lower_part(fingerprint) then we only send
the fingerprint, but send keyID if it's !=?

-derek

To: Nikos Mavroyanopoulos <[email-masked]>
Cc: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 12:21:26 -0500
Lines: 51
Sender: [email-masked]

Nikos Mavroyanopoulos <[email-masked]> writes:

> the notation <20> means an upper limit of 20 bytes in TLS (used in
> RFC2246), so v3 fingerprints can be used. (the specified data are
> encoded with the size).

Ok.  I am unfamilar with the TLS spec, so thank you for clearing this
up.

> > You probably want to send along the keyID as well as the fingerprint.
> > Most implementations can only lookup a key based on the keyID.  As a
> > result, you wont be able to easily lookup v3 RSA keys if you only send
> > the fingerprint.  I would recommend you change the definition to:
>
> I'm not quite familiar with OpenPGP, and I had the impression that v3
> keys were only defined for backwards compatibility. If v3 keys are still 
> in use I could use something like:

That's ok -- I am.  I'm afraid that yes, v3 keys are still in wide
use.  Anyone who generated their key using PGP 2.x and is still using
PGP with that key is de facto using a v3 key.  I, personally, am one
such user.  It is more than just backwards compatibility (IMHO).

> > opaque PGPKeyID<8>
> > opaque PGPFingerprint<20>
> > 
> > struct {
> >     PGPKeyID pgp_key_id;
> >     PGPFingerprint pgp_fingerprint;
> > } PGPKeyDescriptor;
> 
> The first version always sends the keyID (which is redundant in v4 keys).

I'm willing to live with 8 bytes of redundancy.  It's still better
than X.509 ;)

> The second version is a bit complicated, but sends the keyID only for v3
> keys. I don't really like it because (at least since today) TLS did not 
> have to know about X.509 certificates' version explicitly. I think it's 
> better to be that way for OpenPGP keys too.

I agree..  Go with the former and always send the extra 8 bytes of
keyID.

-derek

To: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 17 Jan 2002 18:11:43 +0100
Lines: 27
Sender: [email-masked]

On 17 Jan 2002 09:52:24 -0500, Derek Atkins said:

> You probably do not want to assume that the fingerprint is 20 octets
> long; fingerprints on v3 RSA keys are only 16 octets long.  So, your

Left pad them with zeroes and store the fingerprint as meta data with
the keys or index a DB using the fingerprint.  It might even be easier
to require the use of v4 keys.

> You probably want to send along the keyID as well as the fingerprint.

Frankly, I suggested to drop the keyID because the few extra bytes for
a fingerprint are not an issue and it makes the code easier if we only
have to lookup by fingerprint.

> Most implementations can only lookup a key based on the keyID.  As a

Then they should be fixed. To lookup by keyID you have to calculate
the fingerprint anyway for v4 keys.  And there won't be many v3 keys
in use with TLS.

  Werner

Date: Thu, 17 Jan 2002 18:55:29 +0200
From: Nikos Mavroyanopoulos <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
Sender: [email-masked]

On 17 Jan 2002 09:52:24 -0500 Derek Atkins <[email-masked]> wrote:

Derek, 
 thank you for your comments,

> You probably do not want to assume that the fingerprint is 20 octets
> long; fingerprints on v3 RSA keys are only 16 octets long.  So, your
> definition of PGPFingerprint<20> wont work with all OpenPGP keys.
> Since you're already assuming DSS keys by your 20-octet fingerprint,
> it should be noted that the v4 (DSS) keyID is just the lower 64-bits
> of the fingerprint. (RFC2440: 11.2)
the notation <20> means an upper limit of 20 bytes in TLS (used in RFC2246), 
so v3 fingerprints can be used. (the specified data are encoded with the size).

> You probably want to send along the keyID as well as the fingerprint.
> Most implementations can only lookup a key based on the keyID.  As a
> result, you wont be able to easily lookup v3 RSA keys if you only send
> the fingerprint.  I would recommend you change the definition to:
I'm not quite familiar with OpenPGP, and I had the impression that v3
keys were only defined for backwards compatibility. If v3 keys are still 
in use I could use something like:

> opaque PGPKeyID<8>
> opaque PGPFingerprint<20>
> 
> struct {
>     PGPKeyID pgp_key_id;
>     PGPFingerprint pgp_fingerprint;
> } PGPKeyDescriptor;

or

> opaque PGPKeyID<8>
> opaque PGPFingerprint<20>
> enum { v3, v4 } PGPKeyVersion;
>
> struct {
>    PGPFingerprint pgp_fingerprint;
>    PGPKeyVersion keyVersion;
>    select (PGPKeyVersion) {
>          case v3: PGPKeyID;
>          case v4: {};
>    }
> } PGPKeyDescriptor;

The first version always sends the keyID (which is redundant in v4 keys).

The second version is a bit complicated, but sends the keyID only for v3
keys. I don't really like it because (at least since today) TLS did not 
have to know about X.509 certificates' version explicitly. I think it's 
better to be that way for OpenPGP keys too.

-- 
Nikos Mavroyanopoulos
mailto:[email-masked]

To: Nikos Mavroyanopoulos <[email-masked]>
Cc: [email-masked]
Subject: Re: Fw: [ietf-tls] using openpgp with tls
From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 09:52:24 -0500
Lines: 51
Sender: [email-masked]

Nikos Mavroyanopoulos <[email-masked]> writes:

> Hello,
>  Some days ago I posted to ietf-tls WG mailing list, a modification
> of the draft-ietf-tls-openpgp-01. Since this is about openpgp,
> I decided to post it here too. 
> 
> The original post:
> 
> I wanted to use openpgp certificates with TLS, but
> draft-ietf-tls-openpgp-01 is expired, and had some properties that I did
> not like. Here I modified the tls-openpgp draft in a way that:
>  * no new cipher suites need to be defined, in order to use openpgp keys
>  * does not use keyIDs but key fingerprints
> 
> I'd appreciate any comments on this.

You probably do not want to assume that the fingerprint is 20 octets
long; fingerprints on v3 RSA keys are only 16 octets long.  So, your
definition of PGPFingerprint<20> wont work with all OpenPGP keys.
Since you're already assuming DSS keys by your 20-octet fingerprint,
it should be noted that the v4 (DSS) keyID is just the lower 64-bits
of the fingerprint. (RFC2440: 11.2)

You probably want to send along the keyID as well as the fingerprint.
Most implementations can only lookup a key based on the keyID.  As a
result, you wont be able to easily lookup v3 RSA keys if you only send
the fingerprint.  I would recommend you change the definition to:

opaque PGPKeyID<8>
opaque PGPFingerprintV3<16>
opaque PGPFingerprintV4<20>

struct {
        PGPKeyVersion keyVersion;
        select (keyVersion) {
                case v3: PGPFingerprintV3;
                case v4: PGPFingerprintV4;
        }
        PGPKeyID;
} PGPKeyDescriptor;

And then use the PGPKeyDescriptor in your Certificate structure.

-derek

Date: Thu, 17 Jan 2002 08:51:14 +0200
From: Nikos Mavroyanopoulos <[email-masked]>
To: [email-masked]
Subject: Fw: [ietf-tls] using openpgp with tls
Sender: [email-masked]

Hello,
 Some days ago I posted to ietf-tls WG mailing list, a modification
of the draft-ietf-tls-openpgp-01. Since this is about openpgp,
I decided to post it here too. 

The original post:

I wanted to use openpgp certificates with TLS, but
draft-ietf-tls-openpgp-01 is expired, and had some properties that I did
not like. Here I modified the tls-openpgp draft in a way that:
 * no new cipher suites need to be defined, in order to use openpgp keys
 * does not use keyIDs but key fingerprints

I'd appreciate any comments on this.

2. Certificates

   The X.509v3 [X509] certificates recommended for use with TLS will
   not be used in conjunction with OpenPGP keys.  An implementation
   SHOULD be able to support both TLS with X509 and TLS with OpenPGP
   keys.  It is NOT REQUIRED that an implementation support both.  The
   "peer certificate" in the session state of TLS MAY refer to either
   X509 or OpenPGP.

3. Changes to the Handshake Message Contents

   This section describes the changes to the TLS handshake message
   contents when OpenPGP keys are to be used for authentication. 

3.1 Hello Messages

3.1.1 Extension Type                                  

   A new value, "cert_type(7)", has been added to the enumerated
   ExtensionType, defined in [TLSEXT].  This value is used as the extension
   number for the extensions in both the client hello message and the
   server hello message.  This value was chosen based on the version of
   defined in [TLSEXT] that was current at the time of writing, so may be 
   changed in future.                                

3.1.2 The Client Hello Message

   An extension of type CertificateTypeExtension is appended to the standard 
   client hello message using the client hello extension mechanism 
   defined in [TLSEXT].

   This extension carries a list of supported Certificate types the client 
   can use. This extension SHOULD NOT be used if the client supports only
   X.509 Certificates.

   enum { client, server } ClientOrServerExtension;

   enum { X.509(0), OpenPGP(1), (255) } CertificateType;

   struct {
      select(ClientOrServerExtension) {
         case client:
            CertificateType certificate_type<1..2^8-1>;
         case server:
            CertificateType certificate_type;
      }
   } CertificateTypeExtension;

3.1.3 Server Hello

   The certificate type selected by the server (certificate_type),
   is appended to the server hello message using the hello
   extension mechanism defined in [TLSEXT].
   
   The certificate type selected by the server (certificate_type), 
   is encoded in an CertificateTypeExtension structure, which is 
   sent in an extended server hello message, using an extension of 
   type "cert_type".

   The CertificateTypeExtension structure may be omited if the server
   only supports X.509 certificates.

3.2 Server certificate 

   The contents of the certificate message sent from server to
   client and vice versa are determined by the negotiated certificate
   type and the cipher suite. 

   In case OpenPGP certificate type is negotiated then it is required 
   to present an OpenPGP key in the Certificate message. A OpenPGP 
   key appearing in the Certificate message will be sent in binary 
   OpenPGP format. The Certificate message includes an OpenPGP key 
   where the X.509 certificate would normally appear. 

   The option is also available to send an OpenPGP fingerprint, 
   instead of sending the entire key. The generation of fingerprints
   is defined in [OpenPGP]. The client will respond
   with a fatal alert unsupported_certificate if the key with the 
   given fingerprint cannot be found. If the key is not valid, 
   expired, revoked, corrupt, the appropriate fatal alert message 
   is sent from section A.3 of the TLS specification. 
   If a key is valid and neither expired nor revoked, it is accepted by 
   the protocol. A particular OpenPGP compatible TLS implementation MAY 
   wish to allow users to designate certain keys specifically as Trusted 
   Server Keys.  This is a local matter outside the scope of this document.

   enum {
        key (0), key_fingerprint (1), (255)
   } PGPKeyDescriptorType;

   opaque PGPFingerprint<20>;

   opaque PGPKey<1..2^24-1>
   struct {
        PGPKeyDescriptorType descriptorType;
        select (descriptorType) {
             case key_fingerprint: PGPFingerprint;
             case key: PGPKey;
        }
   } Certificate;

3.3 Certificate Request

   The server is allowed to request a client certificate from the
   client.  The meaning of this message is essentially unchanged to
   allow OpenPGP keys.

   The rsa_sign and dss_sign certificate types may be requested in
   conjunction with OpenPGP keys.  The ClientCertificateType field is
   used identically to the TLS specification.  The subsequent
   DistinguishedName field is NOT included when using OpenPGP keys.

   The Client Certificate message is sent using the same formatting as
   the server Certificate message in response to the Certificate Request
   message.  If no OpenPGP key is available from the client, then
   an empty certificate is returned.  The server MAY then respond with a
   fatal alert if appropriate.  This transaction follows the TLS
   specification.

3.4 Server Key Exchange

   When using ephemeral Diffie-Hellman, the Server Key Exchange message
   is sent to pass the Diffie-Hellman public value to the client.  The
   client and server then use this value to establish the shared secret.
   This is identical to the operation of standard TLS.

3.5 Certificate Verify

   The Certificate Verify message for OpenPGP key types is identical to
   the specification.  The signature is made using either DSS or RSA
   depending on the Cipher Suite.

3.6 Finished

   The Finished message for OpenPGP key types is identical to the
   description in the specification.

4. Supported Key Exchange Algorithms
   
   OpenPGP certificates can be used with the following key exchange
   algorithms:

       Key Exchange Algorithm  Certificate Key Type

       RSA                     RSA public key; the certificate must
                               allow the key to be used for encryption.

       DHE_DSS                 DSS public key.

       DHE_RSA                 RSA public key which can be used for
                               signing.

   The above key exchange algorithms are defined in [TLS].

5. Cipher Suites

   No new Cipher Suites are required, in order to use OpenPGP certificates, 
   but some additional Cipher Suites are defined here in order to support 
   algorithms defined in [OpenPGP] but are not present in [TLS].

   CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_SHA          = { 0x00, 0x?? };
   CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_RMD          = { 0x00, 0x?? };
   CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD      = { 0x00, 0x?? };
   CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD       = { 0x00, 0x?? };
   CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD       = { 0x00, 0x?? };

   CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_SHA          = { 0x00, 0x?? };
   CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_RMD          = { 0x00, 0x?? };
   CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD      = { 0x00, 0x?? };
   CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD       = { 0x00, 0x?? };
   CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD       = { 0x00, 0x?? };

   CipherSuite TLS_RSA_WITH_CAST_CBC_SHA              = { 0x00, 0x?? };
   CipherSuite TLS_RSA_WITH_CAST_CBC_RMD              = { 0x00, 0x?? };
   CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD          = { 0x00, 0x?? };
   CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD           = { 0x00, 0x?? };
   CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD           = { 0x00, 0x?? };

   All of the above Cipher Suites use either the CAST, AES, or
   TripleDES block ciphers in CBC mode.  The choice of hash is either
   SHA-1 or RIPEMD-160. "Export" algorithms also MAY NOT
   be used with OpenPGP keys.  Implementations are not required to support
   the above cipher suites.

6. References

   [TLS]     T. Dierks, and C. Allen, "The TLS Protocol Version 1.0",
             RFC 2246, January 1999.

   [OpenPGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer,
             "OpenPGP Message Format", RFC 2440, November 1998.

   [TLSEXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
             Wright, "TLS Extensions", draft-ietf-tls-extensions-02 (work in
             progress), June 2001.

   [X509]    CCITT. Recommendation X.509: "The Directory - Authentication
             Framework". 1988.

-- 
Nikos Mavroyanopoulos
mailto:[email-masked]

Date: Wed, 9 Jan 2002 16:20:32 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: new patent app conflicts with pgp
Cc: [email-masked]
Sender: [email-masked]

>On 2002-01-08 09:00:42 -0500, vedaal wrote:
>>[C] According to a web page I located, RFC1991 was published August 1996
>>and includes the following text:
>
>See also Schneier, Applied Cryptography 2nd ed, p. 51, for a slightly more
>abstract description.  This is from 1996, too.

If you really want go go back to old stuff, there's the PEM RFCs starting in
1987, OSI (who?) work from the mid 1980's, and assorted conference papers and
research work on secure mail from the same time frame.

Peter.

Date: Tue, 8 Jan 2002 16:58:19 +0100
From: Thomas Roessler <[email-masked]>
To: vedaal <[email-masked]>
Cc: [email-masked]
Subject: Re: new patent app conflicts with pgp
Mail-Followup-To: vedaal <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2002-01-08 09:00:42 -0500, vedaal wrote:

>[C] According to a web page I located, RFC1991 was published August 1996
>and includes the following text:

See also Schneier, Applied Cryptography 2nd ed, p. 51, for a 
slightly more abstract description.  This is from 1996, too.

-- 
Thomas Roessler                        http://log.does-not-exist.org/

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: new patent app conflicts with pgp
Date: Tue, 8 Jan 2002 09:00:42 -0500
Sender: [email-masked]

On Sat, Jan 05, 2002 at 01:53:09PM -0500, John Kane wrote:
>
> Someone has applied for a US patent on the technique of
> using a symmetric session key on a document, and then using
> multiple public keys to encrypt the session key to multiple
> recipients

I forwarded the message with the url to a patent attorney who also happens
to be an avid pgp/gpg user, and on several of the pgp mailing lists, {but
not this one}, and am listing his response below:

Vedaal, please forward this message to the IETF list and anywhere else you
think appropriate.

Below are some facts to ponder. As a patent agent registered to practice
before the U.S. Patent Office, I do advise clients about patentability of
their inventions. Indeed, if a client came to me with this pending
application, I would be in a position to counsel him or her as to whether I
thought it wise to pursue it. However, I do not provide such advice to
anyone but a client in a professional relationship (see disclaimer), so the
legal conclusions of these facts are left to the reader or his or her legal
counsel. Also, please note that the scope of my practice does *not* extend
to analyzing the effect of issued patents, as that is a matter before the
courts and not the Patent Office.

Now on to the facts...

[A]  The independent claims of the Jevans application, as published, are
copied below. All other published claims are dependent on one of these two,
and are thus no broader in scope than these two. I've broken claim 1 into
sections for easier reading.

1. A method for transmitting a message, comprising the steps of
- - encrypting said message to develop an encrypted message,
- - said encrypted message being decryptable using a first decryption key;
- - encrypting said first decryption key with encryption keys of a plurality
of target recipients, to develop a plurality of encrypted decryption keys;
and
- - transmitting said encrypted message and said encrypted decryption keys
to
said target recipients.

22. Apparatus including at least one computer readable storage medium, said
apparatus carrying data comprising: an encrypted message, said encrypted
message being decryptable using a first decryption key; and a plurality of
encrypted decryption keys stored in conjunction with said encrypted
message, each of said encrypted decryption keys including said first
decryption key encrypted with an encryption key of a respective target
recipient of said message.

[B] The application claims priority of a provisional application filed Feb.
24, 2000. Assuming that provisional application fully supports the pending
claims (and that shouldn't be taken for granted), any patent or "printed
publication" that (1) was available to the interested public more than one
year before the provisional's filing date, i.e., before Fed. 24, 1999, and
(2) "discloses, either expressly or inherently, all of the limitations
[i.e., elements] of the claim[s]" would anticipate the claims and render
them unpatentable.

Note that the definition of "printed publication" likely includes RFCs,
which are easily found on any search engine and are publicly available
(i.e., "Distribution of this memo is unlimited").

Even if a reference does not discloses all limitations of a claim, a claim
can be rejected as obvious over a reference or combination of references,
coupled with a clear suggestion in the art (prior published literature,
patents, etc.) that the reference(s) can or should be combined or modified
to arrive at the claimed invention.

[C] According to a web page I located, RFC1991 was published August 1996
and includes the following text:

>"A pgp file consists of three components: a message component, a signature
>(optional), and a session key component (optional)." [5.2]

. . .

>"The session key component includes the encrypted session key and the
>identifier of the recipients public key used by the sender to encrypt the
>session key. The session key component consists of a single
>public-key-encrypted packet for each recipient of the message." [5.2.3]

[D] According to another web page I located, RFC2440 was published November
1998 and includes the following text:

>    A Public-Key Encrypted Session Key packet holds the session key used
>    to encrypt a message. Zero or more Encrypted Session Key packets
>    (either Public-Key or Symmetric-Key) may precede a Symmetrically
>    Encrypted Data Packet, which holds an encrypted message.  The message
>    is encrypted with the session key, and the session key is itself
>    encrypted and stored in the Encrypted Session Key packet(s).  The
>    Symmetrically Encrypted Data Packet is preceded by one Public-Key
>    Encrypted Session Key packet for each OpenPGP key to which the
>    message is encrypted.  The recipient of the message finds a session
>    key that is encrypted to their public key, decrypts the session key,
>    and then uses the session key to decrypt the message.

. . .

>    Note that when an implementation forms several PKESKs with one
>    session key, forming a message that can be decrypted by several keys,
>    the implementation MUST make new PKCS-1 padding for each key.
>
>    An implementation MAY accept or use a Key ID of zero as a "wild card"
>    or "speculative" Key ID. In this case, the receiving implementation
>    would try all available private keys, checking for a valid decrypted
>    session key. This format helps reduce traffic analysis of messages.
> [5.1]

[E] During pendency of their applications, a patent applicant and his or
her representatives are legally bound to disclose to the Patent Examiner
any materials they consider "material to patentability" of the application.
This includes materials sent to them from third parties after they have
filed (and published) the application. Sometimes the submitted materials
are devastating, and the application goes abandoned. Other times submitting
the materials actually winds up helping strengthen the eventual patent
because the Examiner considered the worst "prior art" and still allowed the
claims to issue -- there's a presumption that the Examiner did his or her
job correctly. So don't try this at home, at least not without specific
professional advice.

I hope this info provides some illumination for your continued discussions.
I don't subscribe to the list, so feel free to CC: me if you wish.

Ed Suominen
Registered Patent Agent (http://eepatents.com)
Independent Inventor of Electrical Engineering Technology
U.S. Patents 5,926,513; 5,937,341*; 6,052,748*;
   6,069,913; additional patents pending*  (*Available for licensing)
< Nothing in this message is to be construed as legal advice or
   the opinion of my firm or any client. >

Date: Mon, 7 Jan 2002 17:56:29 -0500
From: David Shaw <[email-masked]>
To: IETF-OpenPGP <[email-masked]>
Subject: Re: new patent app conflicts with pgp
Mail-Followup-To: IETF-OpenPGP <[email-masked]>
Sender: [email-masked]

On Sat, Jan 05, 2002 at 01:53:09PM -0500, John Kane wrote:
> 
> Someone has applied for a US patent on the technique of
> using a symmetric session key on a document, and then using
> multiple public keys to encrypt the session key to multiple
> recipients.  Newton Hammet newton(at)hammet.net brought
> this to our attention.
> 
>   http://appft1.uspto.gov/netahtml/PTO/srchnum.html
>   (search for 20010055396)
> http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html
> http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html
> 
> He cites RSA as prior art, but not RFC1991/RFC2440.

I've not read the patent, but if there really is a prior art conflict
with PGP:

http://www.uspto.gov/web/menu/helpfaq.htm#a50

  #50 How does one file protest on patents that are pending? 

  Protests by a member of the public against pending applications will
  be referred to the examiner having charge of the subject matter
  involved. A protest specifically identifying the application to
  which the protest is directed will be entered in the application file
  if: (1) The protest is submitted prior to the publication of the
  application or the mailing of a notice of allowance under rule
  1.311, whichever occurs first; and (2) The protest is either served
  upon the applicant in accordance with rule 1.248, or filed with the
  Office in duplicate in the event service is not possible.  For more
  detailed information on protesting a patent, you may visit our Web
  site at http://www.uspto.gov/web/offices/pac/mpep/mpep.htm for the
  Manual of Patent Examining Procedure (MPEP) Chapter 1900.

The specific document referred to is at
http://www.uspto.gov/web/offices/pac/mpep/mpep_e8_1900.pdf

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Mon, 07 Jan 2002 22:22:51 +0100
From: Marcel Waldvogel <[email-masked]>
Organization: WandA -- The Waldvogel and Aschwanden Family
To: John Kane <[email-masked]>
CC: IETF-OpenPGP <[email-masked]>, [email-masked]
Subject: Re: new patent app conflicts with pgp
Sender: [email-masked]

John,

It seems to me that PGP is clear prior art in itself to the relevant 
claims, so I don't think we should need to worry.

-Marcel

John Kane wrote:

>Someone has applied for a US patent on the technique of
>using a symmetric session key on a document, and then using
>multiple public keys to encrypt the session key to multiple
>recipients.  Newton Hammet newton(at)hammet.net brought
>this to our attention.
>
>  http://appft1.uspto.gov/netahtml/PTO/srchnum.html
>  (search for 20010055396)
>http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html
>http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html
>
>He cites RSA as prior art, but not RFC1991/RFC2440.
>This seems to be in the context of a business model where
>a server allows secure access to a symmetrically-encrypted
>document by allowing the author to upload multiple
>public-key headers for multiple recipients, and to repost
>both amended PKI access lists and amended updates of
>the document (potentially re-using the orig.sess key).
>
>However:
>  [0024] As another example, encrypted decryption keys could
>  be bundled into the message and the single message with the
>  encrypted decryption keys could be broadcast to all recipients
>  without compromising the security of the mechanism.
>
>--
>John Kane
>Stratham, NH (USA)
>
>
>
>

Date: Mon, 7 Jan 2002 11:39:30 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching
Sender: [email-masked]

R E G I S T E R   N O W ! !

EARLY REGISTRATION DISCOUNT DEADLINE:  January 11, 2002
HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002

FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml.

2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) 
hosted by THE INTERNET SOCIETY 
February 6 - 8, 2002 
Catamaran Resort Hotel, San Diego, California

NDSS is the premier event for security experts around the world. Come to 
the 9th Annual NDSS and share in the latest concepts on the Internet 
security front. Southern California's Catamaran Resort Hotel offers 
spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny 
getaway with opportunities to confer with your security counterparts from 
across the globe.

For more information and on line registration go to the NDSS'02 web site: 
http://www.isoc.org/ndss02.

Questions about registration? Contact Michele Estadt at the Internet 
Society at +1-703-326-9880 ext 104 or send e-mail to 
[email-masked]. Interested in sponsoring a give-away or meal? Contact Martin
Kupres at +1 41 22 807 1444 or send e-mail to [email-masked].

Date: Sun, 6 Jan 2002 11:00:53 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Text canonicalization
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Dec 28, 2001 at 08:15:07AM -0500, vedaal wrote:

> > This sounds very good, but what about detached signatures?  A detached
> > signature doesn't carry the text with it, so wouldn't the the text
> > (presumably delivered via http or ftp, which can change line endings)
> > need to be re-canonicalized for signature verification?  To a certain
> > degree this applies to a clearsigned document as well.
> ...
> also applies somewhat to GnuPG signed and encrypted messages when signed
> with a v3 rsa key, and GnuPG armored signed messages with a v3 rsa key,
> PGP interprets it as a 'detached' signature,
> and 'searches' (unsuccessfully) for the file trying to verify it.
> {not the case with v4 rsa sigs, which seem to act differently}

This is a slightly different problem - GnuPG would never make a
non-clear or non-detached signature with v3 keys that PGP 6 or 7
liked.  I fixed this a few days ago, and it works properly now.

David

Date: Sat, 05 Jan 2002 13:53:09 -0500
From: John Kane <[email-masked]>
To: IETF-OpenPGP <[email-masked]>
CC: [email-masked]
Subject: new patent app conflicts with pgp
Sender: [email-masked]

Someone has applied for a US patent on the technique of
using a symmetric session key on a document, and then using
multiple public keys to encrypt the session key to multiple
recipients.  Newton Hammet newton(at)hammet.net brought
this to our attention.

  http://appft1.uspto.gov/netahtml/PTO/srchnum.html
  (search for 20010055396)
http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html
http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html

He cites RSA as prior art, but not RFC1991/RFC2440.
This seems to be in the context of a business model where
a server allows secure access to a symmetrically-encrypted
document by allowing the author to upload multiple
public-key headers for multiple recipients, and to repost
both amended PKI access lists and amended updates of
the document (potentially re-using the orig.sess key).

However:
  [0024] As another example, encrypted decryption keys could
  be bundled into the message and the single message with the
  encrypted decryption keys could be broadcast to all recipients
  without compromising the security of the mechanism.

--
John Kane
Stratham, NH (USA)

Date: Fri, 4 Jan 2002 14:58:47 -0800
To: David Shaw <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Text canonicalization
Sender: [email-masked]

At 7:33 PM -0500 12/27/01, David Shaw wrote:
>This sounds very good, but what about detached signatures?  A detached
>signature doesn't carry the text with it, so wouldn't the the text
>(presumably delivered via http or ftp, which can change line endings)
>need to be re-canonicalized for signature verification?  To a certain
>degree this applies to a clearsigned document as well.
>

The point of what I'm suggesting is that generating or verifying a
signature is always (or almost always) just hashing the data and going on
with it, no matter what the mode. Text mode comes in when the processing
program can guarantee that the signed data is in canonicalized text. So
most detached sigs must be in binary mode, unless the implementation wants
to transform the text, or otherwise knows that it's in that format. That's
what I mean by it being an assurance. The cryptography is always the same.
Text mode means that if you use a well-defined transform from canonical
form, it will be in the right character set etc.

>Email delivery of the text is a whole other can of worms, though it
>could be argued that if it's email, it should be PGP/MIME.

I suppose that can be argued, but I argue otherwise. I and many other
people delete PGP/MIME without reading, but that's another discussion.
(I've actually been planning such a rant, and was composing it in my head.
Thanks for the opening.)

With regard to text vs. binary, the rule I'm saying is that when you create
a signature, and when you verify it, you process the actual bits in a data
packet, no matter where that data packet is. The crypto sections of an
OpenPGP system ignore the mode.

The interesting problem comes, as I understand it, comes from this scenario:

Alice puts on an FTP server a text file, foo.txt, and a detached signature,
foo.sig. Bob FTPs both files, foo.txt in text mode, and foo.sig in binary
mode, and the line ends get changed as part of FTPing the file.
Consequently, the signature doesn't verify.

I can think of several answers to this scenario:

(1) Don't do that, you'll hurt yourself. Come on, digital signatures are
fragile and brittle. Text mode operations, be they OpenPGP's, FTP's, or
anyone else's, alter text, and that's going to cause problems.

    (a) Alice puts the file on her system in some well-known format that
the right thing will be done with. Examples of this include ZIP files,
.tar.gz, .gz, .Z, .sit, etc. The signature is over the container. Bob FTPs
them both in binary mode, verifies the signature and unpacks foo.txt.

    (b) Bob FTPs both files in binary mode and verifies the signature. Then
he translates foo.txt, or re-FTPs it in text mode.

    (c) Bob's OpenPGP program could tell him that the file seems not to be
in "canonical text" and that this may be the reason why it didn't verify.
This is arguably something of a copout, as it can be irritating to have a
program tell you something didn't work, and here's why. I know I always
mutter to the system, "You're the computer, if it's that easy, fix it."

(2) Bob's OpenPGP program has a heuristic to try to compensate for a text
translation. Note that I said try. There are many, many ways this can fail.
But there are many ways it can work correctly. If an OpenPGP program (or a
wrapper around one -- this is a perfect place to use a perl script) tries
the straightforward thing of converting line ends to CRLF, it will probably
work just fine. If it tries the next simple attempt -- assume that the text
is in ISO Latin-1, and convert it to UTF-8, it will probably get most of
the rest. Certainly most mail things will work right with these.

(3) Put the text file in an OpenPGP clearsigned message. I suppose this
really ought to be (1)(d), as it's another "don't do that" solution. But it
works. If the problem is that you have a file that you want to be both
directly readable as text and signed, clearsigning is a way to go.

I realize that this brings the implementer into a subset of the text
heuristic because line ends might flipped around. But it *should* already
be put into canonical UTF-8, and thus the problem of figuring out how to
verify it is much easier.

	Jon