About RFC 1421 and multiple enhancements:
Steve Kent has said:
Well, go ahead, to be amazed. The PEM spec (1421) is very
explicit about the context in which is is intended to be used. It
does not provided for multiple signatures applied to a single message.
But wait!
RFC 1421 allows for multiple Originator fields, each with its associated
MIC-Info fields. (See Section 4.6.2.1 and 4.6.2.3.) This sounds like
multiple signatures to me.
And the grammar says:
<normalhdr> ::= ...
(1*(<origflds> *<recipflds>)) ; symmetric case --
/ ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
where
<origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>)
<micinfo> ; asymmetric
/ <origid-symm> [<keyinfo>] ; symmetric
If that "1*<origflds>" doesn't mean multiple signatures, then I'm
stumped. I maintain that any semantic confusion possible with parallel
signatures would also be possible with these multiple signatures. (What
does one do if one MIC is verifiable and another is not?) The MIME-PEM
spec allows multiple signatures of this type (it should, we copied the
feature from RFC 1421). So concerns about these multiple signatures
apply to the MIME-PEM spec in exactly the same degree as they apply to
RFC 1421.
It would be possible to design a MIME parallel/serial signature feature,
by employing the signature facility defined in the MIME-PEM spec. But
that's a matter for another day, with a new and separate spec that would
(one expects) define the semantics of the new feature. Indeed, one might
design any number of new features using the MIME-PEM spec -- the problems
one might encounter when designing said new features have no bearing on
whether the MIME-PEM spec itself has problems.
Steve Kent has said:
Although one could,
syntactically, use this facility to add multiple layers of signature
to a single content, the text in 4.4 in no way suggests this as an
appropriate use of the nesting feature.
Text which says "Here is the motivation for this feature" does not
mandate that that is the ONLY allowed use for the feature. (Can you
imagine the world without traceroute using the TTL field for other than
its originally motivated use?) Furthermore, a protocol spec that says
"Here is a feature, which is specified to be legal for this protocol,
that should only be used if the intent is to provide service X and never
if the intent is to provide service Y" -- without a mechanism to
distinguish those uses -- would be a non-optimal spec (understatement!).
All syntactically correct uses of the specified protocol features are
allowed.
Which means that RFC 1421 does provide "multiple layers of signature to a
single content", simply because it specifies a feature that could be used
to provide that service.
--Sandy