SMIME Header application/x-pkcs7-signature failing validation in TTT

[sam....@giantquanta.com]

Our Direct messages are showing a failure regarding the use of protocol="application/x-pkcs7-signature".

Validation results: http://transport-testing.nist.gov/direct/a56b98da-46da-4cc4-9483-d25aeeb27483.html#decrypted

The problem seems to be the TTT's explicit requirement of "application/pkcs7-signature" as prescribed by the RFC. We use OpenSSL to generate our messages, which uses "application/x-pkcs7-signature" (presumably because the status of RFC 5751 is proposed)

The TTT had a similar issue with the validation of the RFC's requirement of the "application/pkcs7-mime" header. This was ultimately corrected by the release of TTT 164 (released 20 June 2013). The relevant change log item reads:

• TTT is now able to parse and decrypt application/x-pkcs7-mime messages.

So the question: given the "application/(x-)pkcs7-mime" precedent can we consider this a bug in the TTT tool?

RFC:
http://tools.ietf.org/html/rfc5751#section-3.4.3.2
http://tools.ietf.org/html/rfc5751#section-3.2.1

[Kyle Meadors]

RFC 5751 is an approved standard. The "proposed standard" listed at the top
of http://tools.ietf.org/html/rfc5751 is in reference to the outstanding
errata on this RFC to be addressed, but those errata do not invalidate its
status nor impact this specific question of the proper MIME media type.

RFC 5751 makes clear that protocol parameter must be application/pkcs7-mime.
The "x-" prefix is a now obsolete way of how IETF/IANA use to indicate media
types were experimental or non-standard. At one point in type, this was a
new media type, but application/pkcs7-mime has been approved and in use
since 1999. There is no reason to keep using it at this time.

I am not the SME or tool author so it is not my decision to make, but I
believe the TTT and the community would be best served by keeping the error
response to application/x-pkcs7-mime. While production-ready EHRs system
should follow the Internet adage of being conservative in what you send and
liberal in what you accept, a good compliance tool should flip that approach
to be liberal in what is sent and conservative in what is accepted to best
engender interoperability across the spectrum of products.

Kyle Meadors
Drummond Group Inc.
Director of EHR Testing
817-709-1627
ky...@drummondgroup.com


* * * * * * * * * * * * * * * * * * * * * * * *
CONFIDENTIALITY DISCLAIMER
This email, including attachments, is confidential and proprietary. It
constitutes exclusive communication solely to the addressee. Any entity
other than the intended addressee is prohibited from use of this
communication for any purpose. This email, including attachments, may not be
distributed, whole or in part.
* * * * * * * * * * * * * * * * * * * * * * * *

-----Original Message-----
From: sam....@giantquanta.com [mailto:sam....@giantquanta.com]
Sent: Monday, September 02, 2013 1:52 PM
To: transport-t...@googlegroups.com
Subject: SMIME Header application/x-pkcs7-signature failing validation in
TTT

Our Direct messages are showing a failure regarding the use of
protocol="application/x-pkcs7-signature".

Validation results:
http://transport-testing.nist.gov/direct/a56b98da-46da-4cc4-9483-d25aeeb2748
3.html#decrypted

The problem seems to be the TTT's explicit requirement of
"application/pkcs7-signature" as prescribed by the RFC. We use OpenSSL to
generate our messages, which uses "application/x-pkcs7-signature"
(presumably because the status of RFC 5751 is proposed)

The TTT had a similar issue with the validation of the RFC's requirement of
the "application/pkcs7-mime" header. This was ultimately corrected by the
release of TTT 164 (released 20 June 2013). The relevant change log item
reads:

. TTT is now able to parse and decrypt application/x-pkcs7-mime messages.

So the question: given the "application/(x-)pkcs7-mime" precedent can we
consider this a bug in the TTT tool?

RFC:
http://tools.ietf.org/html/rfc5751#section-3.4.3.2
http://tools.ietf.org/html/rfc5751#section-3.2.1

--
You received this message because you are subscribed to the Google Groups
"Transport Testing Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to transport-testing...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[kbrady]

This is directly from the Applicability Statment:

 

2.4 Signed and Encrypted Health Content Containers

STAs MUST support the creation and processing of signed and encrypted MIME entities. That is,
they MUST be capable of creating and reading documents that are encrypted as Enveloped Data, as
specified by RFC 5751, with media type application/pkcs7-mime (although STAs MUST be capable of
also recognizing Enveloped Data with media type application/x-pkcs7-mime), where the encrypted
content type is a multipart/signed document, where the first part is the secured Health Content Container
document and the second part is the detached signature.

 

So it basically says what Kyle implied, you must send pkcs7-mime, but be able to receive x-pkcs-mime.

So TTT is correct.

 

Kevin