[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] Re: GitLab
From:       Peter Todd <pete () petertodd ! org>
Date:       2017-05-15 2:16:05
Message-ID: 20170515021605.GA17281 () fedora-23-dvm
[Download RAW message or body]


On Sun, May 14, 2017 at 09:57:45PM -0400, Jean-Philippe Ouellet wrote:
> > Let's assume that (5) would be too cumbersome and error-prone to qualify
> > as "practical." (3) would, again, entail that the machine is no
> > longer airgapped. (4) is inherently risky. The riskiest storage media
> > are, presumably, those with rewritable firmware, such as many
> > conventional USB drives. Even with less risky media (e.g., CD-ROMs or
> > even floppy disks), however, we can't rule out the possibility that a
> > malformed PGP public key block might try to exploit a hypothetical
> > vulnerability in GPG. So, in general, (2) may not be worth the risk.
> > 
> > 
> > [1] https://www.qubes-os.org/security/verifying-signatures/#importing-qubes-signing-keys
> > 
> 
> Uhh... except it *has* signed other keys, for example:
> 
> $ gpg2 --list-sigs marmarek
> pub   rsa4096 2014-03-05 [SC]
> 0064428F455451B3EBE78A7F063938BA42CFA724
> uid           [ unknown] Marek Marczykowski-Górecki (Qubes OS signing
> key) <marmarek@invisiblethingslab.com>
> sig 3        063938BA42CFA724 2014-03-05  Marek Marczykowski-Górecki
> (Qubes OS signing key) <marmarek@invisiblethingslab.com>
> sig          EE570349A603BCB6 2014-03-05  Marek Marczykowski (Qubes OS
> signing key) <marmarek@invisiblethingslab.com>
> sig          DDFA1A3E36879494 2014-04-30  Qubes Master Signing Key
> sig 3        063938BA42CFA724 2014-04-30  Marek Marczykowski-Górecki
> (Qubes OS signing key) <marmarek@invisiblethingslab.com>
> 
> This is the reason we can initially import only the master signing
> key, trust it, and have all other valid Qubes signing keys trusted
> transitively. This is done for example here [1].
> 
> [1]: https://github.com/QubesOS/qubes-builder/blob/3352cd4363a25debd77ced0a1fa752944ac1ef2f/scripts/verify-git-tag#L25
> 

Ah! Well that makes things much easier.

So Marek's Qubes OS signing key (0x063938BA42CFA724) is also not in the strong
set, because it hasn't cross-signed any keys that are. To get it into the
strong set Marek just needs to sign another key in the strong set with that key
and in turn have a strong set key sign 0x063938BA42CFA724. It'd make sense if
he also uses that key to sign the Qubes Master Signing Key, though the last two
steps might not be needed (I'm not 100% sure what exact definition is used for
the strong set). Regardless, the last two steps are cryptographically correct
as all those signatures are valid statements to make, so I don't see any reason
not to do them (modulo security concerns like those Andrew David Wong raised).

Of course, this is all a bit of a silly song and game, but we don't have a good
alternative right now for web-of-trust-based validation. :/

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20170515021605.GA17281%40fedora-23-dvm. \
For more options, visit https://groups.google.com/d/optout.


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]