Subject: RE: IDUP-GSS-API...

From: Carlisle Adams <[email-masked]>
Date: Tue, 25 Nov 1997 18:39:56 -0500

All,

>----------
>From: 	Linn, John[SMTP:[email-masked]]
>Sent: 	Wednesday, November 12, 1997 9:13 AM
>To: 	'CAT-WG List'
>Subject: 	RE: IDUP-GSS-API...
>
>Per the following text, posted to the list on 17 October:
>
>>I believe that Carlisle's request for a WG Last-Call against a revised IDUP
>>draft is consistent with IDUP discussion at prior IETF meetings.  Given
>>that idup-gss-08 is a newly revised document, I propose that a 4-week WG
>>Last-Call period (i.e., to extend until 14 November) is appropriate to
>>enable concerned reviewers to evaluate and comment on this version with
>>regard to its potential recommendation for advancement to Proposed
>>Standard.  If anyone disagrees with this proposed approach, please comment
>>to the list NLT Friday, 24 October. 
>
>Subsequently, several individuals have posted comments relating to the
>idup-gss-08 draft. I'm posting this note as a reminder and renewed
>solicitation: if anyone wishes to make further comments within the WG
>Last-Call period which extends through this week, please do so.

A revised IDUP (-09.txt) was submitted last Friday afternoon.  I believe
it addresses all the comments received on the list regarding this
document.  In particular:

- GSS_S_CONTINUE_NEEDED has been replaced with
IDUP_S_MORE_OUTBUFFER_NEEDED;

- IDUP_S_MORE_DATA_NEEDED has been removed, leaving only
IDUP_S_MORE_PIDU_NEEDED and IDUP_S_MORE_OUTBUFFER_NEEDED, along with a
bit more clarifying text on what these return codes signify;

- GSS_S_BAD_MIC is now used in place of GSS_S_BAD_SIG;

- IDUP_S_DEFECTIVE_VERIF is now used in place of GSS_S_DEFECTIVE_VERIF

- cred_usage values now do not overlap with GSS;

- an (optional) expiration time has been added to PolicyAndTime;

- Target_Info_S and Target_Info_E have been merged into Target_Info;

- it is now stated that sig_token governs if both it and sign_qop_in are
non-NULL;

- prop_oper_id can now be zero;

- the CORBA spec. is now referenced for the definition and usage of
"complete" with respect to evidence;

- (optional) OIDs have been added for the SE and EV protection services;

- the IDUP_Get_token_details call has been modified to return
SE-relevant information as well as EV-relevant information (depending
upon what kind of token was input and how much of this token is
recognized by the underlying implementation)  [this also allowed the
removal of the IDUP_Parse_token call, since this functionality is now
incorporated in the IDUP_Get_token_details call];

- the SE and EV calls have been modified to accept a Boolean input (on
protection) saying whether this is the second (or higher) in a series of
protection calls, and to produce a Boolean output (on unprotection)
saying whether this should be the last in a series of unprotection
calls.  The net effect is that it is now easier to use multiple SE/EV
calls for protection and unprotection, thus further reducing
(eliminating?) the need for the GP calls when using multiple services.
Some explanatory text regarding this is given in Appendix B ("Examples
of IDUP Use");

- "non-repudiation of retrieval" has been removed.

There is perhaps one final issue that should be debated (over the list
or at the meeting or both).  Someone sent mail to me privately saying
that tokens without the GSS-style "framing" were a bad idea because this
breaks the interoperability of independent IDUP implementations [note
that IDUP currently says that the framing is optional (decided by the
mechanism spec.)].  This was discussed at a CAT meeting some time ago.
The problem is that if someone decides to do an {S/MIME / OpenPGP /
whatever} mechanism under IDUP, they probably don't want the framing
because then they lose interoperability with all the non-IDUP
implementations of that mechanism in the world.  On the other hand,
without the framing, an IDUP_Get_token_details call cannot expect to
return anything useful.

My preference (and I believe this was the preference of the attendees of
that CAT meeting, whenever it was) is to leave the framing as optional,
but maybe we need to reconfirm that decision.  Any thoughts?

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Dec 1997 09:56:59 -0800

Carlisle Adams wrote:

> document. 

Unfortunately, it is not yet available from the IETF. Would you be able
to place it on your Web site and give us the URL ?

Thanks,

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21