headers
Michael Young | 1 Dec 2000 20:04

Re: Encoding of hash in El-Gamal signatures


The specification already mentions precautions in ElGamal
signature handling, and provides a reference.

The original question is still valid, though, and I'd also
be interested in seeing clarification.  If the specification
includes ElGamal signatures, it should provide sufficient
definition to achieve interoperability.  For other
algorithms, there is a discussion of how the hash is padded
(where applicable) and what the algorithm-specific fields in
the signature should be.  One might guess that the same
PKCS-1 padding scheme should be used, and that the MPIs
should be the "r" (=g^k mod p) and "s" (=(h-r*x)/k mod p)
values, in that order.  Is that right?  Yes, I could use the
GnuPG source as the specification, but that shouldn't be
necessary.

If you want to argue that OpenPGP shouldn't support this
algorithm, and that it should be removed from the
specification entirely, I wouldn't object.
Permalink | Reply | 0 comments |
headers
Marc Horowitz | 8 Dec 2000 06:51
Picon
Favicon

rfc2440bis-02 comments

Many of these comments come from notes I took on rfc2440, so I may
have some section numbers wrong.  I did compare these notes to the
I-D, and I believe all of them are still relevant.

1. Section 5.2 is vague about how to compute signature types 0x30 and
   0x40.  The document should specify over what data to compute the
   hash to be signed.  There was also a comment in the list archives
   about the description of signature type 0x18, which says

	This signature is calculated directly on the subkey itself,
	not on any User ID or other packets.

   This is tremendously misleading, since the signature is actually
   computed on a hash over a prefix, the key packet, the subkey
   packet, and a trailer.  Section 5.2.4 gives a more detailed
   description of how to compute a subkey binding signature.

2. Section 5.2.4 contains another error.  It states

	Key revocation signatures (types 0x20 and 0x28) hash only the
	key being revoked.

   However, analysis of existing implementations indicates that this
   is incorrect for subkey revocation signatures (type 0x28); like
   type 0x18, both the primary key and the subkey are included in the
   hash.

3. Subpacket 23 (key server preferences) is specified to be "found
   only on a self-signature".  It should say if that means a direct
   key signature (which makes the most sense to me), or something
(Continue reading)

Permalink | Reply | 23 comments |
headers
Werner Koch | 8 Dec 2000 13:04
Picon
Favicon

Re: rfc2440bis-02 comments

On Fri, 8 Dec 2000, Marc Horowitz wrote:

> 3. Subpacket 23 (key server preferences) is specified to be "found
>    only on a self-signature".  It should say if that means a direct
>    key signature (which makes the most sense to me), or something

As with many other subpackets there is no clear definition on what
to do and it is left to the implementor to decide this.  From my
understanding it does make sense to handle such things this way:

  * If it is on any direct key signature, use this one (or exactly
    the one on the latest direct key signure.

  * Otherwise take it from the latest self-signature.  

(I have worked out some more rules and checked them with Hal.
Currently I can't access them - please ask me next week, if you are
interested)

> 4. The document is vague on what constitures "advisory information" in
>    a signature subpacket (section 5.2.3).  I believe that unhashed
>    signature subpackets were a mistake (I can expound on this if

No, they make sense.  It may happen that you need to store some meta
information about a signature which you have to calculate after
signature creation. 

However, a big warning about unhashed stuff should be present.

> 5. There should be a note that the critical bit MUST be ignored on
(Continue reading)

Permalink | Reply | 0 comments |
headers
David M. Balenson | 11 Dec 2000 23:59

ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01)


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

THE INTERNET SOCIETY'S
2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) 
February 8-9, 2001
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Avi Rubin, AT&T Labs - Research
                 Paul Van Oorschot, Entrust Technologies

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss01
EARLY REGISTRATION DISCOUNT DEADLINE:  January 11, 2001

The 8th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

THIS YEAR'S TOPICS INCLUDE:
* IP Traceback
* Authenticating Streamed Data
* ATM Encryption
* Source Authentication for Multicast
* Distributed Certified E-Mail
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Bell | 12 Dec 2000 11:23

Dash-escaping and the Usenet sig convention


It has been suggested that our mail/news client offer an option to "fix
up" the Usenet sig separator in clear-signed messages to
newsgroups/mailing lists - the problem being that the "-- " gets stuffed
to "- -- " with the result that recipients' clients will no longer
recognize and strip the personal signature in response messages.

The dash-escaping leads to complaints about clear-signed messages to
some groups and some users have taken to removing the dash-escaping by
hand. Although this breaks RFC2440, (NAI)PGP clients still seem to
correctly "de-escape" the message and verify the PGP signature.

The question is, how do openPGP clients cope with such messages and what
do other client vendors think about this? Since [open]PGP clients only
need to be able to correctly parse nested ASCII-armored header lines,
and these all begin with five hyphens, it would be possible to make an
exception for lines such as "-- " when doing the dash-escaping.

Munging the "- -- " back to "-- " does seem to yield benefits in inter-
operability (for the sig-sep convention) and acceptability of PGP-signed
messages, but it is important that it doesn't break inter-operability
between PGP clients.

Should RFC2440bis be updated to mention this? Do any existing clients
fall over by spotting that some lines are escaped at the "wrong" depth?

--

-- 
Ian Bell                                           T U R N P I K E
(Continue reading)

Permalink | Reply | 9 comments |
headers
Werner Koch | 12 Dec 2000 13:53
Picon
Favicon

Re: Dash-escaping and the Usenet sig convention

On Tue, 12 Dec 2000, Ian Bell wrote:

> newsgroups/mailing lists - the problem being that the "-- " gets stuffed
> to "- -- " with the result that recipients' clients will no longer

The preferred way to encapsulate OpenPGP messages in mail is by using
MIME as defined in RFC2015.  No need for the old fashioned cleartext
signing.

> The question is, how do openPGP clients cope with such messages and what

It is a matter of the MUA to handle this right.  Mutt for example
does remove the dash escaping even when it does not verify the
signature.

  Werner
Permalink | Reply | 8 comments |
headers
Jon Callas | 12 Dec 2000 17:06
Gravatar

Re: Dash-escaping and the Usenet sig convention

In our last episode ("Re: Dash-escaping and the Usenet sig convention",
shown on 12/12/00), Werner Koch said:

>The preferred way to encapsulate OpenPGP messages in mail is by using
>MIME as defined in RFC2015.  No need for the old fashioned cleartext
>signing.
>

I disagree completely. The correct way to encapsulate messages is with
cleartext. I often delete PGP-MIME messages without reading them because
it's such a pain to deal with them. I commonly use five different mail
readers on four different OSes, and none of them do PGP-MIME reliably.
That's Eudora on Mac and Windows, Outlook on Windows, Netscape and Pine on
Linux and OSX. The biggest pain is on Windows, where it's hard to scrape up
the attachment to put it in a text editor.

>> The question is, how do openPGP clients cope with such messages and what
>
>It is a matter of the MUA to handle this right.  Mutt for example
>does remove the dash escaping even when it does not verify the
>signature.

I agree that this is a MUA and newsreader issue. They should parse out the
quoting. The dash-escape may be ugly, but it's been a part of PGP since day
2, if not day 1.

	Jon
Permalink | Reply | 0 comments |
headers
Ian Bell | 12 Dec 2000 17:42

Re: Dash-escaping and the Usenet sig convention


On Tue, 12 Dec 2000, Werner Koch <wk <at> gnupg.org> wrote:
>On Tue, 12 Dec 2000, Ian Bell wrote:
>
>> newsgroups/mailing lists - the problem being that the "-- " gets stuffed
>> to "- -- " with the result that recipients' clients will no longer
>
>The preferred way to encapsulate OpenPGP messages in mail is by using
>MIME as defined in RFC2015.

In an ideal world, PGP/MIME would be the only way anyone would send PGP
in email...

>  No need for the old fashioned cleartext
>signing.

...however, the reality is that most clients (in terms of numbers
deployed) seem not to be able to cope.

We have been asked to munge the dash-stuffed clear text as in practice
the use of PGP/MIME signed messages causes more complaints than clear-
signed messages, but clear-signing messages causes complaints about
broken sig-seps :-(

>> The question is, how do openPGP clients cope with such messages and what
>
>It is a matter of the MUA to handle this right.  Mutt for example
>does remove the dash escaping even when it does not verify the
>signature.
(Continue reading)

Permalink | Reply | 3 comments |
headers
L. Sassaman | 15 Dec 2000 12:11

Re: rfc2440bis-02 comments


Marc mentioned 5.2.3.17 (Key server preferences) and that reminded me of a
suggestion I wanted to make.

One of the major complaints I hear about PGP key servers is the inability
to delete keys once they are sent to the server. I'd like to request the
addition of two new flags for subpacket 23:

    0x40 = Disabled
    the key holder requests that this key not be returned upon
    a search of the key server.

    0x60 = Enabled
    the key holder requests that this key be returned upon a
    search of the key server.

Keys bearing the disabled flag would either reside on the key server and
never be returned in a search (except perhaps to the administrator), or
they would be immediately deleted upon receipt by the key server.

(The reason for the enabled flag is to reverse the effects of the disabled
flag at a later date. And of course, if neither the disabled not the
enabled flags are set, keys are implicitly enabled.)

__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
(Continue reading)

Permalink | Reply | 21 comments |
headers
Dave Del Torto | 15 Dec 2000 23:22

Re: rfc2440bis-02 comments

At 3:11 am -0800 2000-12-15, L. Sassaman wrote:
>One of the major complaints I hear about PGP key servers is the inability
>to delete keys once they are sent to the server. I'd like to request the
>addition of two new flags for subpacket 23:
>
>     0x40 = Disabled
>     the key holder requests that this key not be returned upon
>     a search of the key server.
>
>     0x60 = Enabled
>     the key holder requests that this key be returned upon a
>     search of the key server.
>
>Keys bearing the disabled flag would either reside on the key server and
>never be returned in a search (except perhaps to the administrator), or
>they would be immediately deleted upon receipt by the key server.

Len,

I'm intrigued by your idea of "disabling" keys as a solution to this
problem. I think it could be a useful addition, even with the
questions it raises.

If the intent is to allow a Alice to effectively Remove her public
key -- even if the keyserver's policy/software doesn't allow her to
Delete it -- then I think this is useful. Of course, this presumes
that Alice still retains her ability to modify the public key.

However, if the intent is to "mask" the presence of Bob's key on the
keyserver in lieu of Deleting it, it's hard to see what sort of
(Continue reading)

Permalink | Reply | 20 comments |

Gmane