True, SCVP clients that assert the OID that drives a server to produce a validity assertion MUST accept and process a signature. But assuming that same client is also implemented to assert simply a return of {path, rev-info}, then it seems reasonable to assume it should also be capable of asserting the flag.
Mike
-----Original Message----- From: Russ Housley [mailto:housley@xxxxxxxxxxxx] Sent: Wednesday, July 14, 2004 12:14 PM To: Michael Myers; Tim Polk; ietf-pkix@xxxxxxx Subject: RE: Unsigned DPD responses for SCVP15
There is no need for DPV clients to assert the flag!
Russ
At 12:16 PM 7/14/2004, Michael Myers wrote: >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 > > > > > > > >