Subject: Re: MDCs and PGP 6.5.1b15

From: [email-masked]
Date: Mon, 17 May 1999 21:29:58 -0700

William H. Geiger III, <[email-masked]>, writes:
> I had done a detailed analysis of this key for the PGP-Keyserver Operators
> group this weekend (I can post here if desired).

Yes, that would be useful to see.

> IMHO the signature looks
> foobared and violates several aspects of RFC 2440. I don't mind creating a
> method to convert X.509 stuff to OpenPGP, I don't even mind the X.509
> certs being encapsulated in a hashed subpacket. But if we are going to do
> all this the end result should be a valid OpenPGP Key that contains the
> following 3 elements:
>
> Valid OpenPGP Public Key Packet
> Valid OpenPGP UserID Packet
> Valid OpenPGP SelfSignature
>
> I don't think that the X.509 packet alone should qualify as a valid
> SelfSignature but instead during the conversion process a OpenPGP
> SelfSignature should be generated. Of course this would require that a
> corresponding OpenPGP secret key be generated during the conversion
> process. Otherwise I really don't see the point of going through the
> conversion process at all.

Most of the time there is no secret key available because the signature
is made by someone other than the person importing the key.  That is
the typical case for an X.509 certificate.  In that case there is no
possibility of creating an equivalent PGP secret key because the secret
key material is not available.

I don't see the X.509 support in PGP 6.5 as something which will be part
of the OpenPGP standard.  X.509 is a complex data format and most PGP
implementations should not have to carry the burden of adding a full X.509
library just to support OpenPGP.  The intention is that X.509 certificates
will get turned into signature packets which other implementations can
ignore without difficulty.  This is done most directly by giving it an
unused public key algorithm, so that no implementations will attempt
to verify the signature.  I used zero, but we could use 100 if that
would help.  Implementations need to be able to handle unrecognized
public key algorithms, even those which are not defined in the current
OpenPGP standard.

I can make changes for version 6.5.1 which will come out in a few weeks
(bug fix version) to address problems which are tripping up current
implementations.

Hal Finney
Network Associates, Inc.

---

From: Werner Koch <[email-masked]>
Date: Tue, 18 May 1999 09:25:32 +0200

> to verify the signature.  I used zero, but we could use 100 if that

So what about this small change:

5.2.3. Version 4 Signature Packet Format

   The body of a version 4 Signature Packet contains:

     - One-octet version number (4).

     - One-octet signature type.

|    - One-octet public key algorithm or a value of zero to indicate
|      that no multi-precision integers follow.

     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket
       data. Note that this is the length in octets of all of the hashed
       subpackets; a pointer incremented by this number will skip over
       the hashed subpackets.

     - Hashed subpacket data. (zero or more subpackets)

     - Two-octet scalar octet count for following unhashed subpacket
       data. Note that this is the length in octets of all of the
       unhashed subpackets; a pointer incremented by this number will
       skip over the unhashed subpackets.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

|    - Zero or more multi-precision integers comprising the signature.
|      This portion is algorithm specific, as described above.

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 18 May 1999 09:30:57 -0400

> key material is not available.

I am missing something here.  You would need the PUBLIC key to validate
the signature.  These are available within the X509 certificate, so you
could use them to come up with a valid PGP signature over the PGP
signature packet (if you own the X509 cert - if you don't you can't vouch
for the validity or would use a PGP key to sign it).

> public key algorithms, even those which are not defined in the current

Unused or "private".  And it doesn't make sense to treat an X.509 RSA key
as not-an-RSA-key, and the same with DSA.  If you are going to use X.509
keys you can pull them into the PGP infrastructure.  And if you have any
secure web browser, you have an X.509 implementation.

It would be better to call this a version 5 signature packet.

And the issue of X.509 being a MAY / SHOULD is different from how it
should be implemented if it exists.  If OpenPGP MAY support X.509, the
details should be discussed here.

> (bug fix version) to address problems which are tripping up current

So my implementation (which has an X.509 implmentation in the same library
as the rest of the crypto) should easily work with what you are doing?

---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 18 May 1999 08:39:23 -0400

In <[email-masked]>, on 05/17/99 

>is made by someone other than the person importing the key.  That is the
>typical case for an X.509 certificate.  In that case there is no

Ok, I see your point here. If the secret key material is not available
during import then I think we should flag the entire key with a new public
key type. My reason for doing this is so standard OpenPGP implementations
know not to use the key as they are unable to verify that it is valid or
not. By adding a new key type it will allow for faster processing as
implementations can make a decision what to do with the key at the
begining of processing rather than waiting until they are done processing
the signature block.

>implementations should not have to carry the burden of adding a full
>X.509 library just to support OpenPGP.  The intention is that X.509
>certificates will get turned into signature packets which other
>implementations can ignore without difficulty.

No problem with that. Actually I like it. I do wonder how much of an
advantage it is to import a X.509 public key into OpenPGP format unless
the corresponding secret key can also be converted. It may be simpler in
such cases to leave them in X.509 format and for PGP to have a separate
database to store the keys. If you think about it, no OpenPGP
implementation is going to be able to make use of these keys unless they
have X.509 support built in:

-- Can't use the key to verify signatures as only X.509 certs are going to
be generated from this key pair.

-- Can't use the key for encryption (or at least they should not) as there
is no way to verify or authenticate the key without X.509 capabilities.

In cases where you have a valid OpenPGP key with a mix of X.509 & OpenPGP
signatures on it (I imagine that this is your eventual goal here) I think
that processing would go a lot smother if we had a new signature type for
these converted X.509 sigs. OpenPGP implementations without X.509 support
could then just skip over these sigs during their processing of the key.

>This is done most
>directly by giving it an unused public key algorithm, so that no
>implementations will attempt to verify the signature.  I used zero, but
>we could use 100 if that would help.  Implementations need to be able to
>handle unrecognized public key algorithms, even those which are not
>defined in the current OpenPGP standard.

According to the RFC a 0 algorithm is an invalid number. IMHO 100 would be
better as it lets the processor know that he is dealing with a
private/experimental packet rather than thinking that the signature had
somehow been damaged (my first impression looking at the key this
weekend). You are correct though, no code should core dump because of the
key in question (IMHO core dumps because of input data is poor design). 

>(bug fix version) to address problems which are tripping up current

Do you know exactly what is triggering the problem? I sent my analysis to
the keyserver list but I haven't heard anything back yet. Other than
changing the algorithm to 100 and my recommendations for a new public key
& sig types I didn't see anything that is a major problem in the format
(my code didn't have any problems with it). IMHO the keyserver folks need
to do some cleanup of their code. :)

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 18 May 1999 13:36:51 -0400

>      - One-octet signature type.

Would this even apply?

> |      that no multi-precision integers follow.

The PGP signature consists of the MPIs, therefore if there are no MPIs,
there is no signature...

>      - One-octet hash algorithm.

Why is anything hashed if the result (except for 2 bytes) has no where to
go?  So should this even be here?

>      - Hashed subpacket data. (zero or more subpackets)

If we can't do anything with the result, why have anything here?  (Also is
it really zero since I think there are some MUST subpackets).  Shouldn't
all this be in the unhashed area if it isn't being hashed, much less
signed?

> |      This portion is algorithm specific, as described above.

Then this is not a signature, so why put it in the signature packet?

Anything without a PGP digital signature belongs in a literal packet, or
perhapse elsewhere.  Hashed but unsigned anything is still being discussed
- i.e. what form the MDC stuff will take.

---

From: Werner Koch <[email-masked]>
Date: Wed, 19 May 1999 09:40:22 +0200

> - i.e. what form the MDC stuff will take.

I proposed this only to help Hal getting PGP OpenPGP conform.  And
with this change your MDC signatures would benefit too.  But okay,
if nobody likes this - forget about it.