On Tue, 2015-03-17 at 09:43 +0100, Kristian Fiskerstrand wrote:
I fail to see how this behaviour is either dangerous,
Take 0x10 as example:
The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the owner
of the key is in fact the person described by the User ID.
Implementation A: may interpret this as "can also include signatures,
where NO check has been made at all" and thus it might
use it to sign other keys (for whatever reason, e.g. a
key-pinning-like method), since it expects that no
other implementation would use such sigs anyway
Implementation B: may interpret this as "the certifier has checked the
identity, but simply doesn't want to tell, how well he
has done so"
Such implementation might then use the untrustworthy
sigs from A.
Well a bit made up,... but I guess you can see what I mean.
signatures (except for 0x11) are treated the same by the
implementations, which is fine.
Which also shows that they're basically useless.
The information is still useful as
metadata when performing manual analysis of a certification network
and depends on a published certification policy by the issuer.
I disagree, if a user wants to tell under which circumstances he
certified another user/key, hey can do so via the policy URL and in fact
this is the only way for analysis to find out what the certification
means to the certifier.
Using the different signature levels as metadata for certification
network analysis would only produce meaningful results, if all would
have agreed upon the same meaning for these different levels - which is
not the case.
uses not being explicit in the RFC does not mean they are vague and
ambiguous, just that they are defined on a per-context / per-CA basis
Which again is the Policy URL, but then you don't need different levels
of user sigs (at least not all of them), just do something like:
http://me.com/pgp-policy?keyfp=<the key's fingerprint> and you can give
back per signature policy information.
Description: S/MIME cryptographic signature
openpgp mailing list