[pkg-gnupg-maint] Bug#817858: Bug#817858: gnupg: tsign domain not documented

[Daniel Kahn Gillmor]

On Fri 2016-03-11 17:35:17 -0500, Clint Adams wrote:
> On Fri, Mar 11, 2016 at 04:42:40PM -0500, Daniel Kahn Gillmor wrote:
>> fwiw, it means "limit this trust signature to only cover certifications
>> of User IDs with e-mail addresses that have the given domain after the @
>> sign"
>> 
>> So if i tsign admin at example.org's key X with a domain of "example.org",
>> then gpg will only be willing to rely on certifications from X over user
>> IDs of the form "blah blah <blah at example.org>"
>> 
>> This is implemented with a specific, custom regex as documented here:
>> 
>>  https://tools.ietf.org/html/rfc4880#section-5.2.3.14
>> 
>> This is the rough equivalent of "name-constrained" X.509 CAs.
>
> So is it accurate to say that if I fetch a key with a uid of the form
> "Ben Wizner <pugnacious at aclu.org>" with a valid signature from you,
> and I tsign all your uids with full trust and depth 1, I should see
> "full" validity on that key whether I have specified the domain as
> "aclu.org" or left it blank?

Yes, i think it should.

In particular, gpg should make the tsig over a regex that looks like
this:

  <[^>]+[@.]aclu\.org>$\0

(RFC 4880 say that it should be null-terminated, though i don't really
understand why)

of course, this regex wouldn't match a raw e-mail address as a user ID,
but perhaps that's a separate issue.

However, in my testing, it looks to me like neither gpg 1.4.x nor 2.1.x
consider regex-scoped tsigs in their verification.  This seems like it
might be an upstream bug.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160311/7a98e210/attachment-0001.sig>