Skip to content

Required Key Flags Breaking Workflows #205

@arudzitis-stripe

Description

@arudzitis-stripe

👋 Hello folks! I want to start by saying I really appreciate the existence of this library and the dedication here to trying to do the right thing.

I wanted to flag that I believe #155 has some unintended consequences and could use a bit more discussion.

We regularly exchange OpenPGP keys with third-party institutions and we we still see on occasion that keys are being created without flags indicating the proper usage. I'm not exactly sure where these keys come from, but they are out there in the wild. Often we do not have the ability to request new signatures on these keys, especially as these keys will work with gpg, which is seen as somewhat of a reference implementation.

Since the change was made on this library, we switched to modifying the key structs after parsing to manually mark them as valid, which is viable, but requires us to keep track of keys we expect to have no flags.

I do wish the RFC was stronger on this topic.

On the other hand, the "communications encryption" flag in a self-signature is stating a preference that a given key be used for communications.

I have (questionably) interpreted that as the flags being optional (indicating a preference) rather than a requirement. But I am open to other interpretations.

(#187 was opened by another user, but it seems that in their case they were able to modify the key.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions