You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
👋 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.)
The text was updated successfully, but these errors were encountered:
👋 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.
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.)
The text was updated successfully, but these errors were encountered: