ietf-openpgp
[Top] [All Lists]

Re: MDCs and PGP 6.5.1b15

1999-05-18 07:45:09
In 
<199905180429(_dot_)VAA27241(_at_)226-132(_dot_)adsl2(_dot_)avtel(_dot_)net>, 
on 05/17/99 
   at 11:29 PM, hal(_at_)rain(_dot_)org said:

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.

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.

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.

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). 

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.

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!! :)
---------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>