Certificate Management over CMS (CMC): Transport Protocols
Note: This ballot was opened for revision 08 and is now closed.
(Tim Polk) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) (was Discuss, No Record, Discuss) No Objection
Section 6., paragraph 0: > 6. Socket-Based Transport I don't understand how a socket-based transport is different from a TCP-based one; please elaborate.
(Sam Hartman) (was Discuss) No Objection
This protocol is very complicated. I think this spec is appropriate for proposed standard. However I think significantly more detail will be required to advance to draft. In particular I think significantly more detail around the behavior of the authenticated data control, encrypted body parts and the use of CMS will be required to actually document what is necessary for interoperability.
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Jon Peterson) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
(David Ward) No Objection
Magnus Westerlund No Objection
(Chris Newman) Abstain
Comment (2007-12-20 for -)
This is a weak abstain (I'm not asking other ADs to join my abstain position). I share Sam's concern about the complexity of these protocols and feel it is unlikely two independent implementations will interoperate. Further, I do not believe the transport document adequately addresses the concerns of BCP 56 (RFC 3205). My technical best judgement supports BCP 56, but it's clear to me the community does not necessarily agree, thus I abstain (neither blocking nor supporting). Some other specific issues I noticed: draft-ietf-pkix-2797-bis-06.txt: The reference to RFC 2279 should be updated to STD 66 / RFC 3629. Further that should be reflected in both the references section and the security considerations section. I am concerned about the use of bare UTF-8 in identifiers without any form of canonicalization. I don't believe it will interoperate. Consider using RFC 4013 or a Unicode normalization from Unicode TR # 15. draft-ietf-pkix-cmc-trans-07.txt: This text: "A file name MUST be included either in a content type or a content disposition statement." is imprecise, uses incorrect terminology and is inconsistent with section 3.2.1 of RFC 3851. A "MUST" is not justified for interoperability (as HTTP interoperates without a filename), the "SHOULD" used by RFC 3851 seems more appropriate. When talking about HTTP over TLS, it's important to reference RFC 2818 as that describes how server certificates are validated (including handling of "*" in domain names and such). The present references are not sufficient for HTTP over TLS interoperability. The HTTP "transport" profile does not specify how HTTP response codes are used for unsuccessful responses. As stated previously, the HTTP "transport" profile does not address the concerns of BCP 56 (RFC 3205). It is my technical opinion that a separate port should be registered for the suite of protocols that use HTTP as a substrate for certificate-related protocol operations. While use of that separate port is not necessarily required in all cases (particularly for backwards-compatibility), I believe the ability to perform traffic shaping, analysis and access control for certificate registration/validation operations separate from general HTTP traffic at the TCP port level would have operational benefits. While this profile of HTTP is better than most in that it actually specifies a fallback rule for HTTP compliance, be aware that HTTP 1.1 is a 167 page specification and this profile has just mandated support for much of that complexity. I wonder if that aligns with real-world practice? I support Lars discuss.