Subject: Re: [ietf-dkim] Base issue: multiple linked signatures

From: Jim Fenton <[email-masked]>
Date: Mon, 01 Jan 2007 22:19:27 -0800

DKIM Chair wrote:
> In discussions with the IESG to sort through their "discuss" comments, 
> I had a talk with Lisa Dusseault, and she had one point that I want to 
> bring back to the mailing list:  I don't think we considered, in our 
> discussions of multiple signatures, multiple *linked* signatures, 
> which could work TOGETHER to convey information, and the protocol 
> doesn't allow that sort of thing.  The way dkim-base is set up, I 
> don't think this could easily be added as an extension, and it'd be a 
> significant change at this point.  Here's the concept:
> * Signer puts on two signatures (maybe as two header records, maybe as 
> one that contains two sigs).
> * One of the signatures has minimal scope, maybe signing only "from:", 
> with l=0.
> * The other signature covers as much of the message as possible... 
> most headers, all the boby.
> * The two signatures work together.  If one verifies and the other 
> doesn't, the verifier can consider what was changed in the message, 
> and possibly use that information to deal with mailing list 
> modifications or whatnot.
>
> One way this might be used is to have one signature that covers the 
> subject header and one that doesn't, to allow the verifier to detect a 
> subject change and decide whether it's OK.  As the spec is now, the 
> verifier would just find the one signature (that doesn't cover the 
> subject) that works, and use that, not considering the other.
I'm not sure where to jump in on the last week's discussion on this 
thread, so I'll go back to the beginning to add my two-cents worth.  My 
thoughts:

1. There is nothing in the base spec that precludes multiple signatures 
from being used in this way, except for the requirement in Section 5.4 
that the From header field MUST be signed.  So it wouldn't be possible 
to detect a modification to the From header field in this way.  However, 
as many others have noted, multiple signatures are an expensive way to 
do this.

2. Providing a way to deal with header field modification was the 
original intent of the z= tag/value.  At the time this was proposed 
(prior to the formation of the WG), there was considerable concern about 
verifiers using z= to "correct" a modification; since the spec does not 
deal with presentation issues at all, there was no way to indicate this 
to the recipient.  Telling the verifier to replace header fields with 
the values from z= seemed heavy-handed, so instead we got the strong 
"diagnostic use only" language not to use the z= values for 
verification.  I would support some gentler language that permits use of 
z= in verification, with particular attention paid to ensuring that a 
new security vulnerability is not introduced.

3. All of this is a very incomplete solution to the message modification 
problem, since it doesn't address body modification.  We already have a 
way to tell if a modified body is the cause of a signature not 
verifying, because the bh= value won't have the correct hash.  My 
solution would be for the modifier to sign the message after 
modification.  The verifier might want to apply reputation, 
accreditation, or other things like local whitelists (all of which are 
out of scope here) to determine whether they "like" that modification 
based on who did the modifying.

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 2 Jan 2007 16:48:59 -0000

>  I would support some gentler language that permits use of z= in
> verification, with particular attention paid to ensuring that a new
> security vulnerability is not introduced.

My recollection is that we had no idea what the security
vulnerabilities would be, nor did we have any proposals for a metric
of deciding when a modified header is "close enough".  An obvious
example is how algorithmically one might purport to tell a subject
addition of [ietf-dkim] from an addition of [v1agra-at-www.sleazy.biz]

So I still think our decision to stay away from the whole thing was
correct.  Either it's the same message and the signature verifies, or
it's not.  I suppose we could tell people that it's OK to use z= as
part of the process of deciding what to do with a message whose
signature didn't verify, but that process is outside the scope of the
spec.

> My solution would be for the modifier to sign the message after
> modification.

Yes indeed.  Any time someone proposes something more complicated than
this, they really need to explain why.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Jan 2007 10:11:06 -0800

On Jan 1, 2007, at 10:19 PM, Jim Fenton wrote:

> 1. There is nothing in the base spec that precludes multiple  
> signatures from being used in this way, except for the requirement  
> in Section 5.4 that the From header field MUST be signed.  So it  
> wouldn't be possible to detect a modification to the From header  
> field in this way.

It may prove a mistake mandating the signing of the From header once  
internationalization becomes common.  The From header mandate  
supports a highly dubious anti-spoofing effort based upon visual  
recognition.  A far more secure alternative applies annotations to  
digitally recognized originators.  Such an annotation scheme does not  
require troublesome From header stipulations and is not susceptible  
to various visual exploits, such as the use of look-alikes or cousin  
domains.

> (prior to the formation of the WG), there was considerable concern  
> about verifiers using z= to "correct" a modification; since the  
> spec does not deal with presentation issues at all, there was no  
> way to indicate this to the recipient.  Telling the verifier to  
> replace header fields with the values from z= seemed heavy-handed,  
> so instead we got the strong "diagnostic use only" language not to  
> use the z= values for verification.  I would support some gentler  
> language that permits use of z= in verification, with particular  
> attention paid to ensuring that a new security vulnerability is not  
> introduced.

When the MTA is expected to verify DKIM signed messages, then the  
issue of signature selection become a fundamental problem not helped  
by the base DKIM draft.  Delving into how headers might be repaired  
only makes this situation worse.

> 3. All of this is a very incomplete solution to the message  
> modification problem, since it doesn't address body modification.   
> We already have a way to tell if a modified body is the cause of a  
> signature not verifying, because the bh= value won't have the  
> correct hash.  My solution would be for the modifier to sign the  
> message after modification.  The verifier might want to apply  
> reputation, accreditation, or other things like local whitelists  
> (all of which are out of scope here) to determine whether they  
> "like" that modification based on who did the modifying.

As signatures can be replayed, white-listing will likely prove  
impossible in many cases.  The assumption used in the base draft is  
that originating headers can be linked by a common domain.  This  
assumption may prove wrong, largely due to expenses in uniting email- 
address domains with that of the transmitting entities.  Transmitting  
entities may wish to sign outbound mail to protect their outbound IP  
address space.  DKIM signed messages are useful for directing abuse  
feedback.  Some large ISPs already experienced problems adding Sender  
headers containing their domain to their customers email messages  
containing different email-address domains.  Clearly, that is not the  
intended use of the Sender headers either.

A rather minor change to the base draft could significantly reduce  
the overhead related to signature selection when verification of a  
specific originating header is being checked.  This significant  
reduction remains possible by eliminating a restriction on the 'i='  
syntax to permit a linkage between a header and the signature even  
when domains differ. DNS records in the header domain can reference  
the signing domain as a means to validate the signature.  This  
approach eliminates a questionable practice of sharing private keys  
or delegating domains en-mass, as currently assumed by the DKIM base  
draft.  This approach provides email-address domain owners greater  
freedom of choice, and dramatically improves correlation of the  
transmitting entity when commonly represented by the signing domain.   
This last point can not be stressed more when there is any  
expectation that DKIM might be helpful at reducing abuse.

The use of CNAMEs to bridge domains represents the same overhead used  
to establish a relationship using a simple reference.  Reference  
association can be done autonomously, which means there is less cost  
related to deployment, while at the same time the transmitting entity  
is afforded greater protection.  Removing the restrictions on the  
'i=' syntax reduces the validation overhead and thus greatly reduces  
DoS risks.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Jan 2007 10:38:47 -0000

On Tue, 02 Jan 2007 18:11:06 -0000, Douglas Otis <[email-masked]>
wrote:

> internationalization becomes common.  The From header mandate supports a  
> highly dubious anti-spoofing effort based upon visual recognition.  A  
> far more secure alternative applies annotations to digitally recognized  
> originators.  Such an annotation scheme does not require troublesome  
> From header stipulations and is not susceptible to various visual  
> exploits, such as the use of look-alikes or cousin domains.

I agree. An unsigned From is a cause for suspicion, but there may
sometimes be valid resons, which the verifier should be allowed to
consider. For example, in EAI the From may get downgraded during transit.
It is not yet clear what would be the best way to get around that problem,
but unnecessarily restrictive "MUST"s are not going to help. "SHOULD"
would have been quite strong enough - no interoperability problem srises.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Jan 2007 10:46:55 -0000

> signature didn't verify, but that process is outside the scope of the

I agree, except that we didn't 'stay away' :-( . Verifiers may develop all  
sorts of strategies for deciding which failed signatures are in fact safe  
to let proceed. Our documents can suggest strategies, but should not try  
to enforce or forbid them. So it is within out scope to the extent that we  
should think about it to the extent necessary to avoid unnecessary  
restrictions.

So by all means point out that 'z=' was intended for diagnostic use, but  
MUST language forbidding other uses is too strong, since again no  
interoperability issue arises.
>> My solution would be for the modifier to sign the message after

But not always practical (e.g. after an EAI downgrade).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jan 2007 10:58:20 +0000

Well, happy new year all.

Having looked through this, I see no consensus for this
addition/change other than perhaps to weaken the "MUST NOT"
on the "z=". Correct me if I'm wrong there.

Was there a suggestion for new text for the "z=" that we can
consider? (Sorry if I missed it.)

Thanks,
Stephen.

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Jan 2007 06:07:33 -0500

> would have been quite strong enough - no interoperability problem srises.

We are talking about Mail Integrity. It doesn't matter what is the 
reason for "middle ware" to make changes blindly and hope we can use 
NEAR PERFECT KLUDGES to secured the survivability of the mail integrity.

The only logical solution is an "authorized" resign.  Whether that is 
practical, thats a different mutated frog that one side doesn't want to 
touch.

The problem here is we are trying to make DKIM fit everywhere and it 
simply can't.

---
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Jan 2007 20:52:24 -0000

> on the "z=". Correct me if I'm wrong there.

No, weakening it is all I am asking for. Then signers/verifiers will be  
able to devise bizarre schemes if they really can't see any other way  
around their problem (which they should try to do if they can).

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 3 Jan 2007 13:38:41 -0800 (PST)

> addition of [ietf-dkim] from an addition of [v1agra-at-www.sleazy.biz]

No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be up to the MUA which could display small
icon allowing user to see what the modification was as an option.

For most cases original value would be just fine as additional/mods
you worry about are mainly those by mail lists, but the issues there
are that some have user-side scripts to sort out email based on these
subject '[..]' subject tags.

>> My solution would be for the modifier to sign the message after

Signing after is completely separate issue. Every server (every 
'administrative domain') in the path is supposed to be able to
sign if it can. However you should not force users to only use
latest signature (otherwise what you have is just crypto-based
replacement for path validation which could be done with a lot
less effort with server/domain ip validation mechanisms), what
you care about is who sent the original which signature matched
listed administrative domain of the sender.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 3 Jan 2007 21:04:20 -0500

> icon allowing user to see what the modification was as an option.

That's one approach, but hardly the only possible one.  Most of the users
I know would find it completely baffling if their mail program showed them
multiple versions of headers and asked whether they liked them.

> For most cases original value would be just fine ...

Can you describe the algorithm to distinguish the cases where the original
value is fine from the cases where it's not?  I hope we agree that we do
not want to spec a verification system that uses heuristics that vary from
one implementation to another.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 3 Jan 2007 19:29:14 -0800 (PST)

> multiple versions of headers and asked whether they liked them.

That's why I said its better not to display it and only show icon for 
those adventurous folks that care. But how it is really shown/not shown
in MUA should be entirely up to MUA implementors.

> value is fine from the cases where it's not?

You took one line without additional context where I gave an example of 
users who have processing script to find mail lists based on subject tags.

BTW - Did you notice that we are talking about email cases where message 
passed through processing system that thought its ok to make modifications
to the originator's header data before further delivery. So is the question
you're asking when its ok to make further modifications to the same message?
[you see the irony here, right?]

> I hope we agree that we do

Standards documents are there to provide common way how something is
done as seen from outside so that other programs/utilities/etc that 
depend/use program implementing standardized protocol know about it.
As such the issue is exactly that community would not want different 
implementations doing it different ways.

That is not to say that each implementation should be modifying header 
fields to make signature match (if this is done or not depends on 
implementations and possibly on setup on particular location), but
it would be good that when it is done, what is done is documented
(i.e. list of header fields that were changed) and reported in standard 
way as well as values that were there before modifications are available 
for additional use by either pre-delivery processing programs/scripts
or post-delivery programs that display email data to the user.

---

From: Hector Santos <[email-masked]>
Date: Thu, 04 Jan 2007 00:56:52 -0500

> consider? (Sorry if I missed it.)

My input on this.

Based on the earlier discussions about this, I found it to be a wasted 
tag with meaningless value because of the idea it was "acceptable" that 
the contents of the tags could be different what the actual header 
values are, including having other header values that were not 
necessarily part of the hashing.

Under those considerations, it could be *only* be used for some 
diagnostic reason only understood by the signer and if there is any good 
reason, I would think it would be for analyzing changed header values.

So if there was an *official* way to determine if a header change did 
take place, then maybe the Z= tag might be useful here for explaining a 
possible signature failure.   We already have the body hash, so if that 
turns out to be ok, then "possibly" a signature failure was due to a 
header change.  But that only be done if a copy of the headers used for 
signing are stored in the z= tag.

If this becomes acceptable, then its quite possible for a verifier to 
short circuit the verification hashing overhead if the h= header values 
do not match z= values.  That would be a big plus in the verifier world.

It is quite possible to use this for checking DKIM signed mail that have 
arrived from list servers.   A specific verifier may wish to do a brute 
force checking concept,  1) first check the h= headers, then if that 
fails, 2) replace the header values with the z= copy and check again.

By far, the typical list server minimum mutations would be:

   1) optionally adding a [listname] tag to the subject line
   2) optionally adding a footer to the body.

Its quite possible for the verifier to resolve the body with the l= 
length, and the subject change, if hashed, with the z= copy.

So if there any proposal for text change here,  I would suggest that the 
z= tag, if used, "SHOULD" include a copy of the hash header values or at 
the very least, the copy of the header "most likely" to change for the 
DOMAIN intentional chosen DKIM MAIL ROUTE of this mail that may suffer 
mail integrity issues.

If anything, change this text:

     Verifiers MUST NOT use the header field names or copied values
     for checking the signature in any way.  Copied header field
     values are for diagnostic use only.

to:

     Verifiers MAY use the header field names or copied values
     for checking the signature and comparing expected header
     values.

---
HLS

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Jan 2007 12:02:06 +0000

Hi Hector,

>     for checking the signature and comparing expected header

Thanks for trying (this may be hard to get right). The problem
with this try is that we have a MAY but have described no
algorithm that a coder can implement.

I think we need some text containing no MUST/SHOULD/MAY at all,
S.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 04 Jan 2007 11:58:25 -0000

> icon allowing user to see what the modification was as an option.

An example of that sort of thing is the downrading process in EAI.

You start with some header

Foo-Header: <utf-8 stuff that wont pass through current MTAs>

and when you find yourself compelled to downgrade it because the next MTA  
doesn't advertise the UTF8SMTP capability, you replace it with:

Foo-Header: <inadequate/partial reformulation of the original in ASCII>
Downgraded: Foo-Header: <RFC 2047 encoded representation of the original  
utf-8>

So if the original Foo-Header was included in the signature, the signature  
is now broken.

One possiblity for subsequently verifying the signature, assuming the  
verifier can be made aware of what has happened (that is where the 'z='  
tag might be needed) is for the verifier to reconstruct the original  
Foo-Header from the Downgraded header, and test the signature on that.

I am not saying that this is the only way or even the best way of handling  
DKIM in an EAI envireonment, because it is not yet clear whether the  
mechanisms that have been proposed for downgrading are sufficiently  
robust, but it is certainly one possibility that has been suggested. And  
whether people will bother to write verifiers that do all that is another  
issue again, but at least the possibility exists.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 04 Jan 2007 12:14:23 +0000

>> If anything, change this text:
...
> I think we need some text containing no MUST/SHOULD/MAY at all,

The current text was the result of significant discussion and a rather careful 
effort to focus on the primary concern.

Take out the normative quality to the text and you lose the real stricture that 
was the entire intent we chose.

Turn the MUST to a MAY has you reverse the agreement that was developed about 
that concern.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Jan 2007 12:23:54 +0000

Dave Crocker wrote:
> The current text was the result of significant discussion and a rather 
> careful effort to focus on the primary concern.

Sorry, I should have been more careful in my typing. What I meant
was the following:

As a result of this thread, the WG consensus on the "MUST NOT" for
"z=" might have changed. In order to see if that's the case, we need
someone to suggest alternate text. I think (maybe I'm wrong?) that
any putative alternative text has to be non-normative since I didn't
see anything like a WG consensus on some specific action to take
on the contents of "z=", so our options seem to be the current
"MUST NOT" or else something non-normative.

When we've a reasonable looking alternative, then we can ask the
change/no-change question.

Stephen.

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 04 Jan 2007 10:39:11 -0600

> someone to suggest alternate text.

IMO, we need some text that (a) makes it clear that a signature 
verification which conforms to this standard must not be based upon the 
z= and (b) which does not give the sense that verifiers may not use the 
z= values at all!

I believe the current text is meant to do (a) but the "checking the 
signatures in any way" language implies (b).

To my way of thinking the language in DKIM-01 was better:

   Verifiers MUST NOT use the copied header field values for
   verification should they be present in the h= field.  Copied
   header field values are for forensic use only.

Perhaps an alternative might be:

    Note:  Signature verification is determined using the content of
    the headers identified by the h= tag.  Copied headers and header
    field values presented by the z= tag are not intended to be used
    for signature verification.  Any signature verification which
    requires the use of the z= tag content does not conform to this
    standard.

Just an idea.  I'm sure there are problems with it.

-- 
Arvel

---

From: John L <[email-masked]>
Date: Thu, 4 Jan 2007 17:24:46 +0000 (GMT)

> You took one line without additional context where I gave an example of users 
> who have processing script to find mail lists based on subject tags.

We all have scripts like that.  What do they have to do with DKIM 
signature validation?

> you're asking when its ok to make further modifications to the same message?

Actually, that's not at all what I was talking about.  I was asking how a 
recipient system can algorithmically distinguish an upstream modification 
that broke the signature but was "ok" from one that wasn't.

I think that we all agree that if the intermediate system re-signed the 
message and we trust that signature, the message is OK.  But the 
discussion in progress is, as far as I can tell, about messages where an 
intermediate system modified but did not re-sign.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 04 Jan 2007 09:36:52 -0800

John L wrote:
> I think that we all agree that if the intermediate system re-signed 
> the message and we trust that signature, the message is OK.  But the 
> discussion in progress is, as far as I can tell, about messages where 
> an intermediate system modified but did not re-sign.
>
I don't think it's at all clear which is the preferred poison. In your 
case, I'd need
to keep a list of domains that I trust, for some value of trust. That's 
rather daunting
in all but the smallest of scales. In the other case, I'd need to either 
analyze the appended
content, or keep around another list of what is and is not a valid 
transformation. The
latter sounds very similar in scope to the re-sign case, while the 
former is something
that spam scanners do in spades today. The other aspect of all of this 
is that the fate-sharing
on the resign case is all wrong: when I decide to accept/not accept a 
message with modifications,
I control my destiny. When I wait for lists to resign, I wait and I wait 
and I wait...

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 4 Jan 2007 12:37:55 -0500

> that broke the signature but was "ok" from one that wasn't.

This is, I think, the key point.  All this post-processing we are discussing 
is about this point and I don't see any value in standardizing additional 
uncertainty about will a signature validate or not.  

> intermediate system modified but did not re-sign.

Agreed.

While there is certainly nothing an RFC can do to prevent receivers from 
attempting to do the kind of message reverse engineering being discussed, the 
current MUST NOT wording makes it clear that the results of that processing 
are not part of the protocol.  Receivers can guess all they want, but don't 
call the result of that effort a DKIM result.  

I believe that having a clear line in the sand, as the current specification 
does, is a good thing.  Once we start down this slippery slope, where does it 
end?  IIRC, this is what the specification says what it says.

Scott K

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 4 Jan 2007 11:17:45 -0800 (PST)

On Thu, 4 Jan 2007, John L wrote:

> We all have scripts like that.  What do they have to do with DKIM signature 
> validation?

It goes along what you asked about when modifying header data to restore 
an original value and validating signature after that might be a problem.

<devil's advocate>
Current text says that "z" value can not be used for signature validation.
So lets imagine an implementor who actually takes it literally but still
wants to do it but also be able to comply with text. Did someone say its
impossible? Not at all! All you have to do is verify the signature once
and find that it did not validate (a trace header text could even be
added saying that). Then you pass it from your right hand [signature 
verifier system] to left [message processing system not doing signature 
verification and thus not subject to "standard" text] that takes
the message and does same thing that was done to it before and modifies 
its header data based on "z" part of the signature. Then left hand passes
it back to the right which does another signature validation this time
on a "new message" with restored header data. The signature passes and
everyone is happy :)
</devil's advocate>

BTW - The above assumes that implementors actually always do according
to standards text in the first place.. Despite efforts by many people in 
IETF that is not at all what happens in real world and if implementors
find it easier to "bypass" certain parts of the standard based on certain
requirements or for better customer experience they in fact do just that. 
Think NAT!

> that broke the signature but was "ok" from one that wasn't.

By using the original values and doing new signature verification.
The question again goes back as to if its ok from recipient point
of view to trust header data added by original sender. In my view
it always is! The only issues are that some recipients do additional
processing that is operationally use these modifications.

> message and we trust that signature, the message is OK.

Actually I don't agree with that at all. Plus this also requires level
of agreement between the recipient and "re-signer" that is not based
on message sender as would be presented to the user.

> But the discussion in progress is, as far as I can tell, about messages 
> where an intermediate system modified but did not re-sign.

Both. In my view having resigner's signature is helpful in determining 
ultimate delivery status of the message, but it is not paramount. I'd
rather see use original user signature if it can be validated even if
additional signatures exist.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 04 Jan 2007 19:56:31 -0000

> change/no-change question.

If you simply s/MUST NOT/SHOULD NOT/, then you are saying, in effect:

"When used for the purposes and in the manner envisaged when this standard  
was written, then signatures have no need to use this tag other than for  
diagnostic purposes. However, if some other purpose becomes apparent, or  
some other manner of achieving the needed security is proposed, then we  
have left open the possibility that this tag may play a part in it".

So SHOULD NOT is the minimal change. But you could as easily omit all  
MUST/SHOULD/MAY stuff and simply explain that "This tag is not intended to  
pay any part in the signature verification process when this standard is  
used for the purposes and in the manner envisaged. But it is not precluded  
that situations may arise where its use may provide security that could  
not have been achieved without it".

All of which is somewhat waffly, but it does not commit us to things we  
might regret. And, in any case, "MUST NOT" is not enforceable, and there  
is no interoperability problem that it prevents, and hence it is a breech  
of RFC 2119 to use it.