Certificate Management over CMS (CMC): Transport Protocols
RFC 5273

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.