looking for reading material

[zhong ming wu]

Thanks for your references.

I have a better understanding of x509 used in SSL/TLS protocol than
openPGP.  So perhaps x509 analogy might help me understand it.

When I issue the following command

gpg --export SUBKEYID

Is this equivalent to generating an intermediate CA and root CA

Let's say I give the output of the above command and give to the end
user and let's say I sign a file with this subkey

When the end user verifies the signature of the file, the user 1)
verifies that the file is signed by the subkey 2) verfies thet subkey
is signed by the master key.  Is this correct?  In fact, step 2 can be
done at the time of key importing and should not have to be done every
time the user verifies a file? Is this correct?

This will be equivalent to when a client connects to the server, the
server presents the client with both its certificate and the
intermediate CA.   The client should already have root CA in the
normal x509 system.


The problem I am having with rpm is that it signed packages with the
subkey without complaint.  When it comes to verifying packages it
complains that subkey id is not its keyring even though i imported
already.  The correct thing rpm should be doing is checking 1) whether
the package is signed by the subkey -- to do this it needs subkey in
its keyring --  2) the subkey is signed by the master public key --
this could have been done when it imported two keys the first time and
not every time it verifies a package.  Is this the correct
understanding?

It must be that rpm only imported the master public key and drops the
public subkey part.   If I can somehow extract the public key of gpg
subkey and feed it to "rpm --import" then rpm might be able to verify
the package but this somehow defeats the web of trust model of
openPGP.  On the other hand rpm itself seems to be not relying on the
web of trust for any of its imported keys.  So, as far as rpm is
concerned the openPGP subkey concept is moot.  Is my understanding
correct?  If I still want to use GPG subkey for rpm signing I need to
extract the public key of the subkey only and feed to rpm.

One more question related to the way openpgpg works:  when rpm
attempts to verify a package signed with a subkey the complaint it
makes contains the subkey ID.  Does that mean that by inspecting a
signed file, an openPGP compliant program like gnupg can tell the ID
of the key used to sign the file?  It does not have to go through the
whole key ring to verify the signature of 1 key, right?


On Sat, Aug 4, 2012 at 5:09 AM, Christian Aistleitner
<christian at quelltextlich.at> wrote:
> Dear Mr. Wu,
>
> On Sat, Aug 04, 2012 at 02:11:49AM -0400, zhong ming wu wrote:
>> They are all signed by the master key
>
> Yes, subkeys are bound to the primary key.
> This binding is realized via a "0x18: Subkey Binding Signature" [1].
>
> And the binding signature on a signing subkey additionally contains a
> subpacket holding a "0x19: Primary Key Binding Signature" [1].
>
>> but it is also possible to take
>> one of the private subkeys and use it on a machine separate from the
>> master-key machine
>
> Yes.
> On the "subkey machine" you'll typically have the primary public key
> (no need for the primary private key), and both the private and public
> subkey.
>
>> >From a sub key machine, if one exports the public key somehow both
>> master and subkey public keys are exported?
>
> Yes.
> I hope for others to correct me, but I do not think that there is any
> option to turn this behaviour off (for public keys). However, this
> behaviour is just what I want. Recall that User IDs (name, email
> addresses) are bound to the primary key. The subkeys typically [4]
> know nothing about the User IDs. However, you can of course use keys
> without User IDs.
>
> You could go round and strip and mangle packets by hand, but it raises
> a red flag for me.
>
>> [ Information on subkeys ]
>> Please point me to books and papers.
>
> RFC 4880 [5] is your friend. Especially:
>   5.5.1. Key Packet Variants
>   5.2.1. Signature Types  (see types 0x18 and 0x19)
>   11.1. Transferable Public Keys
>   11.2. Transferable Secret Keys
>
> Those sections show that primary and secret keys are much alike (when
> stored), how the binding works and show the typical sequence of
> packets.
>
> To have a look at the packets involved in your own keys, try running
>
>   gpg --export | gpg --list-packets
>
> (in a shell). To look just at a single key, use
>
>   gpg --export KEYID | gpg --list-packets
>
> where KEYID is the id of the key to look at.
>
>
> All the best,
> Christian
>
>
>
> [1] http://tools.ietf.org/rfcmarkup?doc=4880#section-5.2.1
>
> [2] http://tools.ietf.org/rfcmarkup?doc=4880#section-5.5.1.1
>
> [3] http://tools.ietf.org/rfcmarkup?doc=4880#section-5.5.1.2
>
> [4] See
>   http://tools.ietf.org/rfcmarkup?doc=4880#section-11
> which "describes the rules for how packets should be placed into
> sequences." Yes, it only says /should/, but there, subkeys do not have
> User IDs.
>
> [5] http://tools.ietf.org/rfcmarkup?doc=4880#section-5.2.1
>
>
>
> --
> ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
>                            Companies' registry: 360296y in Linz
> Christian Aistleitner
> Gruendbergstrasze 65a        Email:  christian at quelltextlich.at
> 4040 Linz, Austria           Phone:          +43 732 / 26 95 63
>                              Fax:            +43 732 / 26 95 63
>                              Homepage: http://quelltextlich.at/
> ---------------------------------------------------------------