From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
If I look at the email and find a satisfactory signature I
am done. If I don't find any signature at all *or I find only
a weak signature* I need to look at the policy.
I don't see why we need to introduce shades of grey (i.e.,
valid but weak signatures) here. The verifier is able to
decide what it considers to be a valid signature.
Your phrasing is equivalent but leads to ambiguity. The purpose of the exercise
here is to eliminate ambiguity.
A signature is VALID with respect to the Key Record. Every recipient that
receives the same sequence of bits should have the same exact value for VALID.
A signature is ACCEPTABLE if it is VALID AND the signing algorithm and
parameters are acceptable. This is a subjective issue and opinions may differ.
I do not see that conflating an objective quantity with a subjective quality
helps here, on the contrary it introduces shades of grey where they are not
required.
This problem is in part due to the use of the language 'treat an invalid
signature as if it was unsigned'. This only holds for base. At the policy level
there are important distinctions that need to be made between messages that are
consistent with policy that bear an unverifiable signature and those that are
consistent with policy and bear unverifiable signatures.
If a
signature uses an algorithm that the verifier considers to be
too weak, it should just consider the signature to be
invalid. Then the original #11 is sufficient.
That is not a good choice since an invalid signature is by definition not in
compliance with a certificate policy that says 'every message has a valid
signature'.
Also I would like to reword 12:
[PROVISIONAL] A domain holder MUST be able to publish a
Practice which enumerates the acceptable cryptographic
algorithms for signatures purportedly from that domain.
To be
12a [PROVISIONAL] A domain holder MUST be able to publish a
Practice which specifies the acceptable application of
cryptographic algorithms for signatures purportedly from that domain.
12b [PROVISIONAL] A domain holder MUST be able to publish a
Practice which specifies the application of multiple
signatures with different cryptographic algorithms for
messages purportedly from that domain.
I disagree with #12 entirely. This addresses a case where
there is a signature that references a key record within the
domain. There is already a tag/value in the key record to
specify the algorithm(s) that are associated with the key.
If there are algorithms that the domain has abandoned using
because they're too weak, they just don't publish any key
records for that algorithm. There's no reason we need to get
this information from a Practice record.
Your approach is broken.
We are both proposing that the algorithm constraints be applied through key
records. According to your proposal there is no way for a policy to specify
which key records must be satisfied.
This means that under yous scheme any signer that publishes a key record for
DSA-2048 before this algorithm is widely supported will be subject to an
upgrade attack. The attacker can attach a signature that references the key
record for DSA 2048 and the majority of recipients will be unable to determine
that the signature is invalid. This is not a problem for BASE because the
message is treated as unsigned. It is a problem for POLICY as it is not
possible to correctly resolve the question of COMPLIANCE. In particular it is
not possible to resolve the following cases correctly
Case 1: Message has a fraudulent signature for the unsupported algorithm, the
signer always signs using a supported algorithm -> NOT-COMPLIANT
Case 2: Message has a valid signature for the unsupported algorithm, the signer
only signs with the unsupported algorithm -> COMPLIANT but UNVERIFIED
The SSP proposal only allows one of the cases to be correctly decided. You can
solve either one of them correctly by choosing the appropriate default. You
cannot get both cases right without being able to determine more detail that nt
current proposal allows.
The correct determination for policy compliance being either COMPLIANT with
policy or NOT COMPLIANT.
I don't remember all the details, but we discussed whether
key records should describe the application of multiple
signatures (other signatures in addition to the one
referencing the key record). We decided not to do that, and
I don't think SSP should be trying to do the same thing again.
NO, the argument was made to punt this to the SSP discussion.
I don't think that either of us wants to reopen this question as an issue for
base. I raised the issue then and was told I had to wait.
So we have the discussion now.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html