On Mon, 17 May 1999 hal(_at_)rain(_dot_)org 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.
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.
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)
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.
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.