Subject: Re: Requirements for SCVP over HTTP

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Sep 2007 15:17:33 -0400

Speaking as an individual, I support the proposed SCVP http text.  I'm
not really sure this says much different than the existing draft, but
if it makes people happy, that's good.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 10 Sep 2007 10:55:19 +0200

>
> Appendix B.  SCVP over HTTP
>
>   This appendix describes the formatting conventions for the SCVP
>   request and response when carried by HTTP.
>
>   In order for SCVP clients and servers using HTTP to interoperate,
>   the following rules apply.
>
>   - Clients MUST use the POST method to submit their requests.
>
>   - Servers MUST use the 200 response code for successful responses.
>
>   - Clients MAY attempt to send HTTP requests using TLS 1.0 or
>   later over port 443, although servers are not required to support
>   TLS.
In which way is this a formatting convention? What is this good for?
Does one expect to give the server access point just as a hostname?
Why port 443?

Doe it mean that even if the server has published that the
access point is http;//scvp.domaine.mane:4711/scvp-service
the client can still try TLS to the same doamin with the point 443?

This is a protocol feature for which there is no requierment at all.

>
>   - Servers MUST NOT assume client support for any type of HTTP
>   authentication such as cookies, Basic authentication, or Digest
>   authentication.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 Sep 2007 11:58:13 -0700

At 10:55 AM +0200 9/10/07, Peter Sylvester wrote:
>In which way is this a formatting convention?

Good catch. The opening sentence should read "formatting and 
transportation conventions".

>What is this good for?

It is good for systems that want the requests to be protected by TLS, 
such as for confidentiality.

>Does one expect to give the server access point just as a hostname?

Nothing is defined for that: it is up to the service operator to let 
the client know the URI for SCVP service.

>Why port 443?

Because that is what HTTP over TLS normally runs on.

>the client can still try TLS to the same doamin with the point 443?

No, it means that if the server wants the client to be able to use 
TLS, the service operator needs to tell the client what URI to use.

>This is a protocol feature for which there is no requierment at all.

A few people asked for it; I don't know if that is considered a "requirement".

--Paul Hoffman, Director
--VPN Consortium

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 10 Sep 2007 13:35:17 -0700

I think the point Peter is making is if the server has published a URI then the URI defines both the port and the use of TLS.
        HTTP defines no TLS, default = port 80,
        HTTPS defines use TLS, default = 443.
If the URI specified a port number, you use the port number specified in the URL and TLS or not is controlled by HTTP or HTTPS. I would simply change HTTP to HTTPS and delete the "over port 443" as it currently implies you must use 443 when 443 is only the default for HTTPS.

- Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, although servers are not required to support TLS.

* -----Original Message-----
* From: [email-masked] [mailto:owner-ietf-
* [email-masked]] On Behalf Of Paul Hoffman
* Sent: Monday, September 10, 2007 11:58 AM
* To: Peter Sylvester; David A. Cooper
* Cc: pkix
* Subject: Re: Requirements for SCVP over HTTP
*
*
* At 10:55 AM +0200 9/10/07, Peter Sylvester wrote:
* >>Appendix B.  SCVP over HTTP
* >>
* >>   This appendix describes the formatting conventions for the SCVP
* >>   request and response when carried by HTTP.
* >>
* >>   In order for SCVP clients and servers using HTTP to interoperate,
* >>   the following rules apply.
* >>
* >>   - Clients MUST use the POST method to submit their requests.
* >>
* >>   - Servers MUST use the 200 response code for successful responses.
* >>
* >>   - Clients MAY attempt to send HTTP requests using TLS 1.0 or
* >>   later over port 443, although servers are not required to support
* >>   TLS.
* >In which way is this a formatting convention?
*
* Good catch. The opening sentence should read "formatting and
* transportation conventions".
*
* >What is this good for?
*
* It is good for systems that want the requests to be protected by TLS,
* such as for confidentiality.
*
* >Does one expect to give the server access point just as a hostname?
*
* Nothing is defined for that: it is up to the service operator to let
* the client know the URI for SCVP service.
*
* >Why port 443?
*
* Because that is what HTTP over TLS normally runs on.
*
* >Doe it mean that even if the server has published that the
* >access point is http;//scvp.domaine.mane:4711/scvp-service
* >the client can still try TLS to the same doamin with the point 443?
*
* No, it means that if the server wants the client to be able to use
* TLS, the service operator needs to tell the client what URI to use.
*
* >This is a protocol feature for which there is no requierment at all.
*
* A few people asked for it; I don't know if that is considered a
* "requirement".
*
* --Paul Hoffman, Director
* --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 Sep 2007 14:31:07 -0700

At 1:35 PM -0700 9/10/07, Trevor Freeman wrote:
>I think the point Peter is making is if the server has published a 
>URI then the URI defines both the port and the use of TLS.
>If the URI specified a port number, you use the port number 
>specified in the URL and TLS or not is controlled by HTTP or HTTPS.

Ah, good point. Sorry I missed what Peter was asking.

>I would simply change HTTP to HTTPS and delete the "over port 443" 
>as it currently implies you must use 443 when 443 is only the 
>default for HTTPS.
>
>- Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, 
>although servers are not required to support TLS.

Yes, that looks better.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 11 Sep 2007 12:34:19 +0200

Paul Hoffman wrote:
>> If the URI specified a port number, you use the port number specified 
>> in the URL and TLS or not is controlled by HTTP or HTTPS.
>
>> I would simply change HTTP to HTTPS and delete the "over port 443" as 
>> it currently implies you must use 443 when 443 is only the default 
>> for HTTPS.
>>

But this means something totally different. It now qualifies version 
negotiation of TLS
or SSL, and not the possibility of using HTTPS by a client or a server.

independant of that, I suggest to add:

"A client MUST be able to support HTTPS and HTTP using default and 
non-default ports."

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Sep 2007 07:30:51 -0700

At 12:34 PM +0200 9/11/07, Peter Sylvester wrote:
>>>- Clients MAY attempt to send HTTPS requests using TLS 1.0 or 
>>>later, although servers are not required to support TLS.
>>
>>Yes, that looks better.
>

"TLS 1.0 or later" is the standard wording being used by the IETF to 
say "you don't have to handle every old version of SSL". It appears 
in other documents as well.

>"A client MUST be able to support HTTPS and HTTP using default and 

Fully disagree. This sounds like clients must support HTTPS, which is 
not what we are saying. Further, this is already covered by the 
requirement to handle RFC 2616, which says ports other than 80 may be 
used.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 11 Sep 2007 17:04:06 +0200

> say "you don't have to handle every old version of SSL". It appears in 
> other documents as well.
I am just saying that the new text  is not what you proposed in your 
initial one.

And why can't we require TLS 1.0 or later in case when a server supports 
HTTPS? I don't think we
have a installed base that only supports SSL V2 or else.

> requirement to handle RFC 2616, which says ports other than 80 may be 
You are right. I forgot that we don't mandate HTTPS.