Re: IDXP status

My belief is that your rewrite is accurate as it stands, and should stay 
that way. If I understand Glenn's issue correctly, he is saying that 
the  requirements document calls for our protocol to do something that a 
protocol simply cannot do. An alternative view would be that we 
interpret the requirements document to have stated the requirement 
rather poorly, and that our protocol does what it "really" meant. I 
think the latter view makes sense at this point.

-John-

On Friday, July 26, 2002, at 10:59 AM, [email protected] 
wrote:

> I have made all the updates I am planning to make, and have posted them 
> in
> the draft-ietf-idwg-beep-idxp-05 memo of June 17, 2002. The last 
> unresolved
> issue of Glenn's is shown below. Unless I hear anything to support 
> Glenn or
> requests to change the wording, the IDXP memo will stay the way it is.
>
> On Mon, 24 Jun 2002, Glenn Mansfield Keeni wrote:
>>> GMK  4. Sec 5 Page 21
>>> ID    The [protocol] SHOULD be able to ensure non-repudiation of the
>>> ID    origin of IDMEF messages.
>>> ID
>>> ID        IDXP supports non-repudiation of message origin through the
> use
>>> ID        of an appropriate underlying BEEP security profile.  The TLS
>>> ID        profile is an example of a security profile that offers non-
>>> ID        repudiation of message origin through the authentication of
>>>
>>> GMK  The above may be misleading. It is not clear how this will be
> done.
>>> GMK  To my knowledge TLS does not guarantee non-repudiation of message
>>> GMK  origin. (It can ensure non repudiation of TLS session origination
>>> GMK  - but that does not ensure non-repudiation of message origin.).
> This
>>> GMK  is probably a message content matter and thus beyond the
> communication
>>> GMK  protocol.
>>>
>>> BSF  Point taken.  I've rewritten this section, hopefully more to
>>> BSF  Glenn's liking.
>> Unfortunately not. non-repudiation of message origin cannot be done by
>> BEEP/IDXP. And non-repudiation of session origin is not what is sought.
>> I would recommend that you drop this. And maybe it should be dropped as
>> from the (protocol) requirement document too.
>
>> Ben Feinstein
>>   Software Development Engineer, R & D
>>   W: 678.585.7865 x6726 F: 770.645.8311 M: 678.772.4126
>>   8302 Dunwoody Pl., Suite 320, Atlanta, GA 30350 www.guardent.com
>> _____________________________________________________
>> G U A R D E N T
>>   Enterprise Security and Privacy Programs
>>
>