Hello
As far as I can see, SCEP is not an RFC yet, but still an Internet Draft
[1]. In Appendix F, it says that a POST message contains "binary PKCS#7
data". It does indeed not mention an explicit Content-Type, but this
seems no more than an oversight: the focus of the document is on doing
SCEP requests via GET, in which case a Content-Type header is not
needed. It 's not because the draft doesn't mention a Content-Type, that
it expects the header to not be set. Actually, as the HTTP RFC says, it
really should be set: "Any HTTP/1.1 message containing an entity-body
SHOULD include a Content-Type header field defining the media type of
that body." [2]
Now I don't know what the correct Media Type is for "binary PKCS#7
data", but there is e.g. application/pkcs7-mime &
application/pkcs7-signature. And setting it to
"application/octet-stream" ought to work anyhow (again from the HTTP
RFC: "If and only if the media type is not given by a Content-Type
field, the recipient MAY attempt to guess the media type via inspection
of its content and/or the name extension(s) of the URI used to identify
the resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".)
As a conclusion, I believe the SCEP draft should be updated to mention
the correct Content-Type in case of POST requests.
[1] http://datatracker.ietf.org/doc/draft-nourse-scep/?include_text=1
[2] http://tools.ietf.org/html/rfc2616#section-7.2.1
Kind regards, Anthony
Op 27/03/2013 21:55, Matthew Hall schreef:
But the SCEP RFC expects it to be sent without any header. How is JSCEP
supposed to do this if Java overrides it with no way to prevent the override?
