headers
Adrian 'Dagurashibanipal' von Bidder | 10 Jun 2002 14:09
Picon

Re: secure sign & encrypt

Yo!

Jumpin' in late... [site-admin: please mark the mail archive at
../ietf-open-pgp/mail-archive as dead, or redirect to the real mail
archive. the charter on
http://www.ietf.org/html.charters/openpgp-charter.html still points to
the old location, so I assumed the list was dead. Just being nosy: the
agenda in the charter seems pretty much outdated, too. How does the
current agenda of the wg look like?]

As the one who apparently sparked this particular instance of this
discussion (remember
http://www.imc.org/ietf-openpgp/mail-archive/msg04314.html )

http://www.imc.org/ietf-openpgp/mail-archive/msg04373.html and the fact
that it's always difficult to prove that you have not done something or
that you do not possess some information convinces me that both ESE (or
SES) and my proposed 'intended encryption key' extension will never work
out. It all boils down to the fact that cryptography cannot replace
trust. So: No, I don't want to reopen this discussion.

Other comments to issues raised in this thread:

Something seemed odd throughout the discussion (the one I had on
gnupg-users, as well as the one you had here, which I only just found):
Tools (e.g. software) are made to automate and ease some tasks. The user
employs tools to get something he wants. It's not that tools are just
around until a user comes along and thinks 'oh, my, what may I do with
/that/?' So, if the user's expectations and the current behaviour of the
tool disagree, I'd want the tool fixed, not the user. To me, it seemed
(Continue reading)

Permalink | Reply | 0 comments |
headers
john.dlugosz | 10 Jun 2002 20:09
Picon
Favicon

RE: secure sign & encrypt


From: John Dlugosz

Emails are the only thing where we might have missing context information.
In an informal note typed by a person, it might assume the conversation in
progress.  But what contract or other formal document doesn't list the
parties as part of the document content?  And what does "intended
recipient" mean for things that are not messages sent to somebody?

If an application wants to automatically add context information before
signing, without messing up the document proper, then a general purpose
"extra information" field is needed, since "TO:" is just a special case of
this general problem.  And I think it's been said that a suitable field
already exists.

Terje Braaten <Terje.Braaten <at> concept.fr> <at> mail.imc.org on 05-30-2002
12:38:22 AM

Sent by:    owner-ietf-openpgp <at> mail.imc.org

To:    "OpenPGP (E-mail)" <ietf-openpgp <at> imc.org>
cc:
Subject:    RE: secure sign & encrypt

Michael Young writes that "The intended recipient is only one of many
pieces of context that a user might mistakenly believe was included
in the signed material." That is correct, but I will still argue that
the information on which keys the message is encrypted to (or intended
to be encrypted to) is special, and belongs in the OpenPGP standard.
(Continue reading)

Permalink | Reply | 0 comments |
headers
john.dlugosz | 10 Jun 2002 20:16
Picon
Favicon

Mailing List metaissue


From: John Dlugosz

Any idea why the list sent me 15 copies of this?
I've been getting dups from several of y'all, but this one just keeps on
going and going...

"Brian M. Carlson" <karlsson <at> hal-pc.org> <at> mail.imc.org on 05-30-2002
02:15:10 PM

Sent by:    owner-ietf-openpgp <at> mail.imc.org

To:    Terje Braaten <Terje.Braaten <at> concept.fr>
cc:    "OpenPGP (E-mail)" <ietf-openpgp <at> imc.org>
Subject:    Re: secure sign & encrypt

On Thu, May 30, 2002 at 07:38:22AM +0200, Terje Braaten wrote:
>
> Michael Young writes that "The intended recipient is only one of many
> pieces of context that a user might mistakenly believe was included
> in the signed material." That is correct, but I will still argue that
> the information on which keys the message is encrypted to (or intended
> to be encrypted to) is special, and belongs in the OpenPGP standard.
>
> It is not only mail that can be signed and encrypted with OpenPGP,
> it can be all kinds of electronic documents and messages. When f.ex.
> an "X-To-PGP-Key" header might be an adequate solution for e-mail
> messages, it will not fit at all for other sorts of messages.
> In fact, the only meta data about a message that is common to all
> encrypted messages is the recipient public keys. And since this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Terje Braaten | 10 Jun 2002 20:24
Picon

RE: secure sign & encrypt


john.dlugosz <at> kodak.com wrote:
> 
> Emails are the only thing where we might have missing context 
> information.
> In an informal note typed by a person, it might assume the 
> conversation in
> progress.  But what contract or other formal document doesn't list the
> parties as part of the document content?  And what does "intended
> recipient" mean for things that are not messages sent to somebody?

Everything that is "signed & encrypted" has a list of recipients that it
is encrypted to. This list of recipients is included in the protocol. That
is why I mean the protection of this information by signing it also belongs
in
the protocol.

> 
> If an application wants to automatically add context 
> information before
> signing, without messing up the document proper, then a 
> general purpose
> "extra information" field is needed, since "TO:" is just a 
> special case of
> this general problem.  And I think it's been said that a 
> suitable field
> already exists.
> 

I think you have completely missed my point here. Please read what
(Continue reading)

Permalink | Reply | 56 comments |
headers
Kazu Yamamoto | 27 Jun 2002 12:25

Secret Key Packet Formats


Hello all,

I have several comments on Section 5.5.3 (Secret Key Packet Formats)
of 2440bis-05. 

>     - [Optional] If secret data is encrypted, Initial Vector (IV) of
>       the same length as the cipher's block size.

The following might be more easy to understand.

      - [Optional] If secret data is encrypted(string-to-key usage
        octet was not 0), Initial Vector (IV) of the same length as
        the cipher's block size.

>     - Encrypted multi-precision integers comprising the secret key
>       data. These algorithm-specific fields are as described below.

If string-to-key usage octet was 0, this field is not encrypted. So,
this should be:

      - Plain or encrypted multi-precision integers comprising the
        secret key data. These algorithm-specific fields are as
        described below.

>     - If the string-to-key usage octet was 255, then a two-octet
>       checksum of the plaintext of the algorithm-specific portion (sum
>       of all octets, mod 65536). If the string-to-key usage octet was
>       254, then a 20-octet SHA-1 hash of the plaintext of the
>       algorithm-specific portion. This checksum or hash is encrypted
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 1 Jul 2002 21:11

photo support?


Is there a standardized way to embed photos in OpenPGP keys?  Anyone
interested in writing such a standard?
Permalink | Reply | 9 comments |
headers
vedaal | 1 Jul 2002 21:49
Picon
Favicon

Re: photo support?


----- Original Message -----
From: "Simon Josefsson" <jas <at> extundo.com>
To: <ietf-openpgp <at> imc.org>
Sent: Monday, July 01, 2002 3:11 PM
Subject: photo support?

> Is there a standardized way to embed photos in OpenPGP keys?  Anyone
> interested in writing such a standard?

as it is now, it is definitely 'different' for PGP and GnuPG.

PGP compresses the .jpg into the photo id, and does not export it when
exporting the key.

GnuPG leaves the .jpg intact as added by the user, and exports it intact as
part of the .asc

if PGP downloads a public key with a photo id, that was generated by GnuPG,
it will export a photo as part of the .asc, but 'altered/compressed'.
the exported .asc of the public key will be different than the exported .asc
of the GnuPG key.

as a side-issue,
since the .jpg of a GnuPG generated photo-id is left intact,
it is possible to steganographically embed data within the key id photo
which can be retrieved intact from anywhere by downloading the key from an
ldap server.

it is possible to store a conventionally encrypted pgp file containing a
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Shaw | 1 Jul 2002 23:06

Re: photo support?


On Mon, Jul 01, 2002 at 09:11:05PM +0200, Simon Josefsson wrote:
> 
> Is there a standardized way to embed photos in OpenPGP keys?

Yes.  I documented the existing PGP method for the latest 2440bis
draft.  Both PGP and GnuPG use this method.

It is actually a very general "embed anything" system.  Photos are
just the only currently defined attribute to be embedded.

David

--

-- 
   David Shaw  |  dshaw <at> jabberwocky.com  |  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
Permalink | Reply | 0 comments |
headers
Hal Finney | 1 Jul 2002 22:57

Re: photo support?


Vedaal writes:
> if PGP downloads a public key with a photo id, that was generated by GnuPG,
> it will export a photo as part of the .asc, but 'altered/compressed'.
> the exported .asc of the public key will be different than the exported .asc
> of the GnuPG key.

I don't think it re-compresses the JPEG, I'm not aware of any code that
would do that.  However it is possible that there is some incompatibility
between GPG and PGP in the handling of photo IDs.  Can you provide me
with a GPG-created key with a photo ID, and I will see what happens to
it with PGP.

Hal Finney
Permalink | Reply | 0 comments |
headers
Michael Young | 1 Jul 2002 23:55

Re: photo support?


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

Subject: Re: photo support?

From: "vedaal" <vedaal <at> hotmail.com>
> this can lead to an overburdening of servers with 'bloated' keys, with
> whatever someone may decide to want to 'store'.

This is hardly unique to the "photo ID" field.  It would be easy to "store"
arbitary content in:
    a notation subpacket in a valid signature;
    signature MPIs;
    user names; or, even
    public key MPIs.

It is impossible to prevent this sort of abuse without seriously impairing
legitimate use of the public keyservers.

One man's garbage is another man's key.

> it might be worthwhile to consider some maximal size for a recommended
> standard, which can be implemented by the servers
> refusing to accept a key greater than a certain size.

A size recommendation seems reasonable, as an implementation guideline.
A strict limit in the protocol seems most unreasonable.

This kind of restriction alone won't prevent abuse.  It's only the tip
(Continue reading)

Permalink | Reply | 0 comments |

Gmane