RE: IDUP Compatibility of call sets

Bengt.Ackzell@AIT.400net.tip.net Mon, 02 February 1998 22:09 UTC

Delivery-Date: Mon, 02 Feb 1998 17:09:03 -0500
Return-Path: owner-cat-ietf@pad-thai.cam.ov.com
Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA06601 for <ietf-archive@ietf.org>; Mon, 2 Feb 1998 17:09:02 -0500 (EST)
Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA04491; Mon, 2 Feb 1998 17:11:44 -0500 (EST)
Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA02396 for cat-ietf-redist; Mon, 2 Feb 1998 15:33:56 -0500 (EST)
From: Bengt.Ackzell@AIT.400net.tip.net
X400-Received: by mta mswitch in /ADMD=SWITCHgate/C=ch/; Relayed; Mon, 2 Feb 1998 21:32:48 +0100
X400-Received: by /ADMD=SWITCHHOP/C=CH/; Relayed; Mon, 2 Feb 1998 21:35:22 +0100
X400-Received: by /ADMD=400NET/C=NL/; Relayed; Mon, 2 Feb 1998 21:33:35 +0100
X400-Received: by /ADMD=400NET/C=SE/; Relayed; Mon, 2 Feb 1998 21:33:31 +0100
Date: Mon, 2 Feb 1998 21:33:31 +0100
X400-Originator: Bengt.Ackzell@AIT.400net.tip.net
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/ADMD=400NET/C=SE/;MHSP25MHBB R0019000886451610074]
Original-Encoded-Information-Types: teletex
X400-Content-Type: P2-1984 (2)
Message-Id: <"8314 98/02/02*/G=Bengt/S=Ackzell/O=AIT/ADMD=400net/C=SE/"@MHS>
To: "'cat-ietf@mit.edu'" <cat-ietf@mit.edu> (Non Receipt Notification Requested)
In-Reply-To: c=CA%a=_%p=NorTel_Secure_Ne%l=APOLLO-980121190906Z-5:
Subject: RE: IDUP Compatibility of call sets
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id PAA02394
Precedence: bulk

Carlisle,

The implementation twists to provide cross-use of GP and EV(SE) calls ought to be 
indicated.
Add a paragraph/note in the GP text describing this. 

/Bengt Ackzell

>The corresponding entity in the GP calls is the (input parameter)
>service_verification_info in Unprot_Service.  This is specified in IDUP
>to be of type Service_Verification_Info, which is described as a
>mechanism-defined parameter bundle.

>I tried to make this as general as possible (in keeping with the GP
>calls themselves), by allowing total freedom in number and type of
>parameters in the Service_Verification_Info bundle.  However, in
>practice I think that most mechanism specifications will simply define a
>single parameter which is an opaque OCTET STRING, thereby allowing what
>you are proposing above (i.e., that evidence may be generated by an EV
>call and verified by a GP call, or vice versa).