java-utils-mail-smime icon indicating copy to clipboard operation
java-utils-mail-smime copied to clipboard

getStatus doesn't determine the S/MIME status correctly according to RFC

Open bbottema opened this issue 6 years ago • 1 comments

According to RFC 5751 (S/MIME 3.2), to determine if a message was signed or encrypted, the media type (primary-/sub type) value as well as its parameter smime-type should be taken into consideration:

3.2.2. The smime-type Parameter

 The application/pkcs7-mime content type defines the optional "smime-
 type" parameter.  The intent of this parameter is to convey details
 about the security applied (signed or enveloped) along with
 information about the contained content.

A little bit down an example is shown of a signed-only message:

A sample message would be:

  Content-Type: application/pkcs7-mime; smime-type=signed-data;name=smime.p7m

SmimeUtil doesn't look at smime-type at all when determining status and has resulted in incorrect status for a message of mine.

bbottema avatar Apr 15 '19 13:04 bbottema

More specifically, it misses the case for enveloped S/MIME content. Here's the fixed code:

private static SmimeStateFixed getStatus(ContentType contentType) {
	if (isSmimeSignatureContentType(contentType)) {
		return SmimeStateFixed.SIGNED;
	} else if (isSignatureSmimeType(contentType)) {
		return SmimeStateFixed.SIGNED_ENVELOPED;
	} else if (isSmimeEncryptionContenttype(contentType)) {
		return SmimeStateFixed.ENCRYPTED;
	} else {
		return SmimeStateFixed.NEITHER;
	}
}

private static boolean isSignatureSmimeType(ContentType contentType) {
	String baseContentType = contentType.getBaseType();
	return baseContentType.equalsIgnoreCase("application/x-pkcs7-mime")
			&& "signed-data".equals(contentType.getParameter("smime-type"));
}

The caught exception in the original method is really problematic, hiding other possible errors that has nothing to do with S/MIME (like programming bugs).

bbottema avatar Jul 26 '20 07:07 bbottema