Skip to main content

Certificate Management over CMS (CMC): Transport Protocols
draft-ietf-pkix-cmc-trans-08

Yes

(Tim Polk)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)

Abstain


Note: This ballot was opened for revision 08 and is now closed.

Tim Polk Former IESG member
Yes
Yes () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
(was Discuss, No Record, Discuss) No Objection
No Objection (2007-12-19) Unknown
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.
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection (2007-12-14) Unknown
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.
Chris Newman Former IESG member
Abstain
Abstain (2007-12-20) Unknown
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.