>From: Sandy Murphy <sandy(_at_)tis(_dot_)com>
>Subject: Re: limitations of mime-pem transformation
>Date: Thu, 29 Dec 94 17:07:09 EST
>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
>
There is a (no-so-) subtle difference between one originator signing
twice, and two originators signing in some groupware application. When
one user spans multiple authenication domains, its useful for the same
certified and naming-authority-registered user to allow each recipient
in the different domains the capability to verify the signature and
hence determine identity. However the auhtneitcation semantics is
clear, there being a single service; that there are two bit strings to
facilitate two levels of system assurance, or to cater for two
different crypto communities is not an issue. There must be only one
DN, only one identity, and therefore only one I&A decision for use by
authorization enforcement logic.
Like Ned, you are redefining terms, and of course can then find
contradiction in the meaning. You played with the authentication
semantics; now you are getting burned.
allied comment:-
Its in this area that Marshall's and Bob insistance on Certificate DNs,
and Naming Authority DNs being optionally different breaks down with
the introduction of non-identity but service-oriented or
application-specific attributes into the DN in the certificate. Sounds
nice, but breaks the individual accountability assurance rules and
hence I&A functions.
Now one can have such attributes in a DN, if there is means to ensure
that they are not distinguished. but this assumes either an Interent
std naming schema with which to ascertain the semantics (proposed by
Steve Kent, but rejected by Marshall, Stef, and Co, when in their
red-hot NADF-Internet interworking phase), or an on-line directory whose
information model and access protocol ensure the naming rules are
enforced for certs.
In any case, the application and service-orinted information is now
correctly placed in ancillary extensions, in the being-ratified X.509
defect process.