I would add one other requirement. Clients MUST be capable of asserting the flag.
Mike
-----Original Message----- From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Tim Polk Sent: Wednesday, July 14, 2004 6:50 AM To: Russ Housley; ietf-pkix@xxxxxxx 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
At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:
>My personal preference Option #2; however, I think that absence of this >flag should indicate that the response should be signed. One needs to >make a guess about deployment to select the best semantic for this >situation, and my guess is that server authentication will be important. > >Russ > > >Trevor Freeman wrote: >>I have been asked to add unsigned responses for DPD clients to SCVP15. >>There are two models proposed on how we accomplish that both of which >>meet the requirements for 3379. I would therefore like some feedback on >>how the group views the two mechanisms >> >>Global Server Policy that it is DPD only >>The first proposal is to make the option controlled by the server as a >>global policy. Therefore the server would publish via policy that is only >>supports DPD as such never signs a response. DPV client and DPD clients >>wanting a signed response then know to use another server. >> >>SCVP Request option to not sign response >>The second option is to leave it to the client to signal to the server it >>does not need a signature on the response by a new flag in the request >>(or its twin the flag indicates it does want a signature on the >>response). This allows clients to be benevolent towards the server by >>asking it to skip the signature. Server can still at their discretion >>still sign. >> >>Needless to say it is possible to hybridize the two but I am hopeful we >>can try and keep this as simple as possible be picking on of the two. >>Trevor > > > >