RE: Unsigned DPD responses for SCVP15

["Terry Hayes" <thayes0993@xxxxxxx>]

Mike,

The client should not be required to have this capability.  If a client applicatio will never assert the flag because of its operating environment and policy, why should it be required to implement code that can set it?  The need to assert the flag (or not) can be predicted ahead of time in some environments.

Terry


Michael Myers wrote on 7/14/2004, 11:57 AM:
> 
> I thought we were done too until I read more carefully your proposed 
> text.  I do believe the requirement is necessary or I wouldn't have 
> brought it up.  The need to assert the flag cannot be 100% predicted 
> ahead of time.  Given the presumptive definition of the flag, I believe 
> interoperability would benefit.  It doesn't say the flag must be used, 
> but only that the capability we all worked so hard on to define is an 
> assumption rather than a stovepipe. 
> 
> Mike 
> 
> 
> 
> -----Original Message----- 
> From: Tim Polk [mailto:tim.polk@xxxxxxxx] 
> Sent: Wednesday, July 14, 2004 11:18 AM 
> To: Michael Myers; Russ Housley; ietf-pkix@xxxxxxx 
> Subject: RE: Unsigned DPD responses for SCVP15 
> 
> 
> 
> Mike, 
> 
> Geez... read your last message and thought we were done! 
> 
> I don't believe this requirement is necessary.  An SCVP client that 
> doesn't 
> perform local path validation (i.e., a DPV client *only*) doesn't need 
> to 
> be able to assert this flag.  An SCVP client that is designed to always 
> perform local path validation (i.e., DPD *only*) might be designed so 
> this 
> was configurable, or could be designed to always assert this flag. 
> 
> Let's drop this one and claim victory/bipartisan agreement/etc... 
> 
> Thanks, 
> 
> Tim 
> 
> At 09:16 AM 7/14/2004 -0700, 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 
> > > 
> > > 
> > > 
> > >