I agree with Mr Ford's first point stated below. In fact, I would prefer to
see a binding of the mosskey-data item to the associated moss-signed item.
That would simplify handling of multiple signed items and associated data items
in one mesage.
Phil Smiley
-------------
Original Text
From warwick @ SMTP (warwick)
{pem-dev-request(_at_)neptune(_dot_)tis(_dot_)com}, on 5/2/95 7:02
PM:
To: PDevelo @ SMTP (PEM Developer's Mailing List) {pem-dev(_at_)TIS(_dot_)COM}
(I have been trying to send this for 4 days but the pem-dev server has been
bouncing it. One more try...)
Re MIME Object Security Services, two issues discussed at length on this list
during the review of the previous draft of this document have not been dealt
with properly, i.e., the current draft does not reflect the spirit of the
concensus reached in discussions.
(1) There is no indication of how a certificate or certificate chain can
accompany a moss-signed content type in the same message. This is a capability
provided by RFC 1421 which MOSS needs also to support. In pem-dev discussions
on the previous draft, it was resolved that the way to achieve this was to
convey a mosskey-data item in the same message, prior to the moss-signed item.
To make this clear in the draft, it would be adequate to add, in section 6, an
example showing this type of content type combination. My understanding is
that
the I-D authors agreed to do this for the new draft. However, this example has
still not been included. It needs to be added before the draft can progress to
proposed standard.
(2) Sec. 4.2. Description of the KEYSEL field. The current wording says "A
suggested value is to use a portion (low-order 16 bits or 32 bits) or all of
the
actual public key used". Given the substantial debate on this topic, and the
final clear lack of concensus that an approach such as lower-order bits of the
public key is desirable, inclusion of the above statement does not reflect the
concensus of the discussion. Delete this sentence.
Warwick