Subject: [drinks] Review of draft-ietf-drinks-spp-protocol-over-soap-02

From: Dean Willis <[email-masked]>
Date: Mon, 10 Sep 2012 21:47:24 -0500

In 7.1.2 Public Identity Object Key

we have:

   It is MUST that only one of the "number", "range", and "uri" elements
   appears in a PubIdKeyType instance

This might be better worded as:

    Any instance of PubIdKeyType MUST contain exactly one element from the following set of elements: "number", "range", "uri". 

Section 11: Security Considerations makes TLS a SHOULD, and 11.1 makes it a MUST IMPLEMENT. Didn't we agree to a MUST USE? Note that 11.3 allows non-encryption … it's weasely.

11.1 discusses authentication alternatves, but doesn't section 5 mandate Digest?

Section 5 says:

5.  Authentication and Session Management

   To achieve integrity and privacy, conforming SPP Protocol SOAP
   Clients and Servers MUST support SOAP over HTTP over TLS [RFC5246] as
   the secure transport mechanism.  This combination of HTTP and TLS is
   referred to as HTTPS.  And to accomplish authentication, conforming
   SOAP SPPF Clients and Servers MUST use HTTP Digest Authentication as
   defined in [RFC2617].  As a result, the communication session is
   established through the initial HTTP connection setup, the digest
   authentication, and the TLS handshake.  When the HTTP connection is
   broken down, the communication session ends.

but 11.1 says:

11.1.  Integrity, Privacy, and Authentication

   The SPP Protocol over SOAP binding relies on an underlying secure
   transport for integrity and privacy.  Such transports are expected to
   include TLS/HTTPS.  In addition to the application level
   authentication imposed by an SPPF server, there are a number of
   options for authentication within the transport layer and the
   messaging envelope.  These include TLS client certificates, HTTP
   Digest Access Authentication, and digital signatures within SOAP
   headers.

   At a minimum, all conforming SPP Protocol over SOAP implementations
   MUST support HTTPS.