looking for reading material

[Daniel Kahn Gillmor]

On 08/05/2012 04:38 AM, zhong ming wu wrote:
> 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

i note that your subkey should have the "signing" usage flag set.  That
is, it should show up under gpg --edit-key with "usage: S".  Otherwise,
that subkey has no business signing data and its signatures *should* be
ignored.

 key usage flags:

  https://tools.ietf.org/html/rfc4880#section-5.2.3.21

Note that signing- or certification-capable subkeys should also have an
embedded primary key binding signature, to indicate that they really do
belong to the primary key.

 primary key binding sigs:

  https://tools.ietf.org/html/rfc4880#page-71

> 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?

sure, those steps seem reasonable.

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

i don't think your X.509 analogies are as close as you'd like them to
be.  In standard TLS connections, each peer hands their certificate (and
any intermediate certs) to the other peer as part of establishing the
connection.

Most data signed via OpenPGP does not have *any* certificate ("openpgp
keyblock") directly attached to it.  The common assumption in this model
is that public key material has been exchanged via some other mechanism
already.

> 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?

What you describe does sound like a bug in rpm's signature validation
policy.  I haven't tested it myself.

> 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? 

Most OpenPGP signatures contain the 64-bit keyid of the signature issuer
in an "issuer subpacket":

 https://tools.ietf.org/html/rfc4880#section-5.2.3.5

Technically, multiple keys can have the same 64-bit keyid -- the 64-bit
space is too small to avoid collisions made by a determined attacker
(among other possible threats).

But in the common use case, this is sufficient to greatly reduce the
number of keys the verifier needs to consider when checking the signature.

> It does not have to go through the
> whole key ring to verify the signature of 1 key, right?

I'm not sure what you mean by "go through the whole keyring" -- if rpm's
keyring, like gpg's, is unindexed, then rpm will need to go through the
keyring to find the key that matches the keyid found in the issuer.  It
does not need to check the signature against any of the non-matching
keys, though.

hth,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120805/06e283aa/attachment.pgp>