Web of Trust and validation of keys

Kristian Fiskerstrand kristian.fiskerstrand at sumptuouscapital.com
Sat May 12 21:58:49 CEST 2018


On 05/12/2018 06:09 PM, franek.wiertara wrote:
> Hi
>  
> I am sorry if you find my comment a little less understanding. English
> is not my first language. Hopefully, I have described my problem clearly
> enough :)
>  
> I have two problems.
> 1. I am not entirely sure what exactly marginally valid keys do and when
> they become marginally valid. I thought keys would either be valid or not!

marginally trusted isn't valid, the threshold is set using
--marginals-needed n
              Number of marginally trusted users to introduce a new key
signer (defaults to 3)

i.e you need 3 signatures by default on a keyblock/uid for it to be
treated as valid, if you don't have that it isn't.

> 2. I am also not fully confident in understanding Web of Trust. I have
> just got some bits today :)
>  
> I realised, after reading the The GNU Privacy Handbook, if a key becomes
> valid due to the Web of Trust or signed personally, it can "participate"
> in validation of next keys, depending on my trust. What exactly happen
> if a key is marginally valid?

marginally valid -> not valid -> trust level doesn't matter (excluding
ultimate trust that isn't to be used for other people's keys in these
scenarios anyways)

>  
> I also provided some scenarios based on the website and an example of a
> network:
>  
>           .---> Blake ---.
>          /                \
> Alice ---                   ---> Chloe ---> Elena ---> Geoff
>          \                /          \
>           *---> Dharma --*            \
>                           \            \
>                            *----------->*---> Francis.
>  
> Let's say Blake's and Dharma's keys are always valid because they are
> signed by Alice. In case any of those keys are fully trusted, Chloe's
> and Francis' keys will be fully validated. If Both Blake's and Dharma's
> keys are marginally trusted, Chloe's key will be still fully validated
> but Franci's will only be marginally validated.

For Chloe's key to be validated in this scenario you'd require a direct
path from Alice since there isn't 3 marginally trusted signatories
(unless you introduce one from outside the schema).

>  
> Now, when Chloe's key is fully valid, what happen to Elenaa's key? Will
> it become a fully or marginally valid key? I think it depends on whether
> I fully or marginally trust Chloe's key.

Presuming Chloe's key is valid, yes, what happens down the chain depends
on the trust level of this keyblock.

>  
> There is lot of situations when keys can become marginally valid. I am
> guessing, marginal validation sort of blocks a further validation on the
> path. I am wondering why we are not simply to say that a key can be

Blocks, how?

> either valid or not? What am I missing? What is the consequence of a
> marginal validation?

It has the potential of becoming valid if signed by more marginally
trusted people (or directly by someone with full trust)

>  
> Thanks
>  
> PS. For the example, I followed the assumptions from the website: "...
> two marginally-trusted keys or one fully-trusted key is needed to
> validate another key. The maximum path length is three."
>  
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"If you are successful, you may win false friends and true enemies.
Succeed anyway."
(Mother Teresa)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180512/f1df3593/attachment-0001.sig>


More information about the Gnupg-users mailing list