[openpgp] Re: adding validate-userid to the sopv subset

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2025-05-01 10:52:05 -0400, Michael Richardson wrote:
> Daniel Kahn Gillmor <[e-mail]> wrote:
>     > I'm looking at adding sop's "validate-userid" subcommand (which does
>     > simple one-hop User ID validation from a set of fully trusted
>     > authorities) to the next revision of the sopv verification-only subset.
>
> So the answers the question: can I (given my current "trust anchors",
> e.g. "trust ultimate") validate userid XYZ?

yep, that's right.

>     > My reasoning for this is that the functionality from an OpenPGP
>     > perspective is very similar -- it's just a different type of OpenPGP
>     > signature being checked.  And, it would make it possible to use a sopv
>     > implementation to implement identity-checked signature verification.
>
> Yes, it sounds reasonable, but it does stray into keyring management.
> I agree that it fits into stateless, no secret key, etc. though.

To be clear: The Stateless OpenPGP command line interface itself ("sop")
already has a "validate-userid" subcommand, which does what is described
above.  My question here is whether it makes sense to add it to "sopv"
(the verification-only subset of sop)

> Who/when would use it?
> Would it be used in, for instance, SBOM verification?

I could imagine it being used, for example, in validating signatures in
a e-mail.  For example, consider an automated system that accepts some
control messages over e-mail; it only accepts them from specific senders
and only when they're cryptographically signed.

The incoming e-mail has a "From" address, and the system has a set of
trust anchors, and it knows which OpenPGP certificate has correctly
signed the e-mail…  what is it missing?  Assuming we're working within
the model that cryptographic certificates are bound to e-mail addresses,
the thing missing is the connection between the "From" address and the
certificate that signed the message.

   sopv validate-userid --addr-spec-only "$from_address" anchors.cert < signing.cert

ought to be able to make that work.

If folks have other scenarios, i'd certainly be interested -- not
entirely sure how it would work out for SBOM verification.

>     > There is also a separate request to make "validate-userid" fancier than
>     > a simple one-hop validator (See
>     > https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/121) but for sopv
>     > 1.2 i'm inclined to just keep it at a one-hop mechanism for the moment.
>
> In the olden days, I would use one of the find a path from A->B web sites to
> do that... then discover which people I needed to bug to sign some key so
> that we'd have a trusted path.

Right, this kind of pathbuilding is a more complex process than what i'm
asking about for sopv right now.  It's also substantially more dubious.
Just because i'm convinced that certificate A belongs to Alice doesn't
mean that i should be willing to rely on Alice's assertion that
certificate B belongs to Bob.

So the "trusted path" idea is actually a pretty strange one, and even if
we're talking about "trust signatures" (certifications with OpenPGP
"trust subpackets"), that approach has a lot of surprising twists to it
(e.g. see the recent discussion on https://dev.gnupg.org/T7611 )

So for the moment, sop (and sopv) is sticking with a one-hop model, but
i'd encourage anyone interested in the pathfinding approaches to weigh
in on #121, and maybe offer an MR that addresses the raised issues.

   --dkg