Subject: Re: MDCs and PGP 6.5.1b15

From: [email-masked]
Date: Mon, 17 May 1999 09:36:24 -0700

> I think I found a reason why NAI argues against MDCs in signature
> packets.

No, that has nothing to do with why we feel that MDCs should be
associated with encryption packets.  MDCs are not signatures and are not
syntactically replaceable with signatures.  They do not have the same
semantics as signatures and should not be put into signature packets.
Digital signatures are a well defined cryptographic concept and we have a
packet for that purpose.  MDCs are a different cryptographic entity and
they should go into different packets.  MDCs only work in the context
of an encryption envelope and so they should be associated with an
encryption context.

> There is a key which caused some key servers to crash and
> it seems that this one has been created by a new PGP version.  The
> key looks like this:
>
> :public key packet:
>         version 3, algo 1, created 838857600, expires 0
>         pkey[0]: [1024 bits]
>         pkey[1]: [17 bits]
> :user id packet: "Thawte Server CA <[email-masked]>"
> :signature packet: algo 0, keyid 0000000000000000
>         version 4, created 0, md5len 0, sigclass 10
>         digest algo 1, begin of digest 00 00
>         hashed subpkt 2 len 5 (sig created 1996-08-01)
>         hashed subpkt 3 len 5 (sig expires after 24y158d23h59m)
>         hashed subpkt 5 len 3 (trust signature)
>         hashed subpkt 100 len 795 (?)
>         unknown algorithm 0

I will post information shortly with the formats of this PRIVATE signature
subpacket, which does hold an X.509 certificate.  The picture above is
inaccurate in one respect; it does not have a keyid of 0, rather there
is no keyid subpacket.  X.509 certs use a different method to link
issuing keys to signatures, and a keyid cannot meaningfully be used in
this context.

> So we have all the stuff Tom proposed for MDCs in signature packets:
> keyid of zero and a public key algorithm identifier of zero.  The
> private subpacket with id 100 maybe a X509 certificate - I have not
> analyzed it.

It differs from Tom's proposal in several ways, not least because the
signature class of 0x10 indicates that it is a key certificate signature
and not a message signature as the MDC would presumably be.  We use a
PK alg of zero because the certificate validation has to be done using
special X.509 rules.

> If this has really been created by PGP, why didn't tell NAI us about
> it?  

It uses a private subpacket.  That's what the private subpacket is for,
so that vendors can extend the standard for their own uses.

> Tom, what about changing your MDC to use a unhashed subpacket for the
> MDC instead of an MPI?  I think this will be a much nicer solution and
> I wonder why we didn't came up with this earlier.

This would not address the other problems with using a signature packet
for this purpose.

Hal Finney
Network Associates, Inc.

---

From: Tom Zerucha <[email-masked]>
Date: Mon, 17 May 1999 20:19:03 -0400

On Mon, 17 May 1999 [email-masked] wrote:

> MDCs are a different cryptographic entity and they should go into
> different packets.

As an aside, the first does not imply the second.  The spec does not state
that packets map to cryptographic entities (though it ends up this way for
the most part).  And I think the 1-pass signature prefix packet uses a
different packet type number although it is functionally part of the
trailing signature.

Then again, the new encryption scheme is the same type of cryptographic
entity so then should use the same packet as the existing encryption.

> MDCs only work in the context of an encryption envelope and so they
> should be associated with an encryption context.

True, but the question is where or how the association happens.  Do we put
a post-it on the document or on the inside of the envelope, or use glue
or write directly on the document.

> issuing keys to signatures, and a keyid cannot meaningfully be used in

A PGP key ID is derivable from an X.509 cert.  If you use openssl to fill
a key structure with the appropriate information and pass that to one of
my routines it will derive the corresponding ID as if the X.509 key
material was a PGP key. (goodies/x509topk.c)

> so that vendors can extend the standard for their own uses.

Does it violate other rules about the signature packet?  The spec does not
allow for a signature without one (RSA) or two (DSA or even ElGamal) MPI
integers (unless you are using a private, experimental PK algorithm), plus
you need the all the hash stuff in their places.

Stuff all the private packets you want there, but the rest of the rules
about what MUST be there and the valid ID numbers still apply (0 is not
valid for a private, experimental PK algorithm).

I don't know about this particular signature packet or extension, but I
would hope you aren't violating any part of the existing spec with this
addition.

---

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 17 May 1999 22:35:22 -0400

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

>would hope you aren't violating any part of the existing spec with this

I had done a detailed analysis of this key for the PGP-Keyserver Operators
group this weekend (I can post here if desired). 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.

-- 
---------------------------------------------------------------
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: Werner Koch <[email-masked]>
Date: Tue, 18 May 1999 09:12:40 +0200

> SelfSignature but instead during the conversion process a OpenPGP

We should not discuss the contents of private packets here.  I mailed
this only as an explanation why we mighgt have those problems with the
signature packets.  And becuase the public key algo 0 violates the
RFC, we should only dicusss, whether it might make sense to allow such 
an extension.  

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