RE: IDUP Compatibility of call sets Mon, 02 February 1998 22:09 UTC

Delivery-Date: Mon, 02 Feb 1998 17:09:03 -0500
Received: from (cnri []) by (8.8.7/8.8.7a) with ESMTP id RAA06601 for <>; Mon, 2 Feb 1998 17:09:02 -0500 (EST)
Received: from ( []) by (8.8.5/8.8.7a) with ESMTP id RAA04491; Mon, 2 Feb 1998 17:11:44 -0500 (EST)
Received: (from daemon@localhost) by (8.8.8/8.8.6) id PAA02396 for cat-ietf-redist; Mon, 2 Feb 1998 15:33:56 -0500 (EST)
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, 02 Feb 1998 21:33:31 +0100
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: "''" <>
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 id PAA02394
Precedence: bulk


The implementation twists to provide cross-use of GP and EV(SE) calls ought to be 
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).