Subject: RE: Unsigned DPD responses for SCVP15

From: "Dave Engberg" <[email-masked]>
Date: Wed, 14 Jul 2004 10:23:17 -0400

I have a mild preference for defaulting to "unsigned permitted if no request
flag present", but would also be happy with Tim's proposal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tim Polk
Sent: Wednesday, July 14, 2004 9:50 AM
To: Russ Housley; [email-masked]
Subject: Re: Unsigned DPD responses for SCVP15

I also prefer the client-side flag option.  However, I *strongly* believe
that the default behavior (i.e., in the absence of the flag) should be
"signature is REQUIRED" on the SCVP response.

In this way, the default behavior for SCVP always satisfies the 
requirements specified in RFC 3379.   Where the client has explicitly 
determined that source authentication is not required, the client may
explicitly state this.

I believe this option boils down to four fairly simple statements.

(1) Where an SCVP request omits the "not going to authenticate" flag, the
server is required to sign the response or return an error.

(2) Where an SCVP request includes the flag, the server may include or omit
the signature on the response.  (So, a server that *always* signs responses
doesn't need to process this flag...)

(3) An SCVP client MUST NOT assert the "not going to authenticate" flag and
request a statement about validity.

(4) Where the request did not assert the new flag, the SCVP client MUST
process the digital signature on a response.

I believe these changes would result in a protocol whose default behavior
satisfies all the requirements in 3379, permits the employment of unsigned
messages for DPD, and precludes any ambiguity in the implementation of mixed
mode servers.

Tim Polk