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 <server-certs(_at_)thawte(_dot_)com>"
: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.