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.
Sigh. My mistake then. I missed this completely (amazing what one little 1* can
do in EBNF). Sandy is absolutely right here -- both classic PEM and MIME/PEM
appear to offer parallel signature services at the same level. No extensions
are needed to achieve this. You would only need an extension in MIME-PEM to
allow for multiple signatures using different underlying services (e.g. PEM and
PGP).
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.
This is exactly what I've been trying to say, but Sandy's description of it
here is much better than mine was.
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.
Exactly right.
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.
And if the intent of Working Group in RFC 1421 was to only provide services
with the very limited semantics it presents in its examples (which I doubt), I
feel that the only viable course of action is for the specification to be
immediately withdrawn and replaced with a new version that changes the BNF,
bans nesting of secured objects, and mandates that only one security enclosure
can appear in a given message.
Such a specification would be so limited as to be nearly useless, of course.
Ned