From: Russ Housley <housley(_at_)spyrus(_dot_)com>
All:
ESS currently includes this definition.
EncapsulatedContentType ::= CHOICE {
built-in ...
external ...
externalWithSubtype ... }
External is an OID, and it is similar to the content type carried in
signed-data. We could eliminate the built-in if we assigned OIDs for each
of the few integers that are assigned. This would simplify the structure.
The externalWithSubtype will not be used often, and the subtype is not
really important in the receipt request context. It is really used to flag
that automatic processing of the message is necessary. Therefore, I
propose moving the subtype to a separtae authenticated attribute.
If people accept both of these proposals, then the ESS document should use
the content type attribute defined in the CMS document.
ESS included the definition of EncapsulatedContentType, which was used
only in ReceiptRequest and Receipt. Since both of these structures
include the mandatory field signedContentIdentifier which uniquely
ties the receipt to the request, there would seem to be no reason
to also include the OPTIONAL encapsulatedContentType field.
Instead of replacing EncapsulatedContentType with ContentType, I
propose that the content type field be deleted entirely from
the two structures, yielding:
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
Receipt ::= SEQUENCE {
version Version,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
( Note that if the inclusion of EncapsulatedContentType was an attempt
to accommodate X.411 delivery reports, it was a highly incomplete
attempt. X.411 defines:
PerReportDeliveryFields ::= SET {
subject-submission-identifier SubjectSubmissionIdentifier,
content-identifier ContentIdentifier OPTIONAL,
content-type ContentType OPTIONAL,
original-encoded-information-types ... OPTIONAL,
extensions [1] IMPLICIT EXTENSIONS CHOSEN FROM {
message-security-label,
content-correlator,
originator-and-DL-expansion-history,
reporting-DL-name,
reporting-MLA-certificate,
report-origin-authentication-check } DEFAULT {} }
So selecting just the content-type field for inclusion in S/MIME
receipts in no way enables support for X.411 delivery reports. )
If there is no requirement satisfied by the inclusion of an optional
contentType in ReceiptRequest and Receipt, then that field should be
eliminated.
Dave Kemp