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

From: Carlisle Adams <[email-masked]>
Date: Wed, 5 Nov 1997 14:45:33 -0500

Hi Denis,

>----------
>From: 	Denis Pinkas[SMTP:[email-masked]]
>Sent: 	Tuesday, October 28, 1997 8:26 PM
>To: 	Carlisle Adams
>Cc: 	'John Linn'; [email-masked]'
>Subject: 	Re: IDUP-GSS-API...
>
>First, I appreciate the extension to four weeks to review the document
>as originally proposed by John. Placing the document on last call is
>indeed the best way to solicit comments. This document has, up to now,
>created little traffic on the mailing list but since it has been
>established for a long time it would be nice to have it passed to the
>next stage at the meeting in Washington. 
>
>There are some issues on the document that I would like to raise. The
>second one is not new to Carlisle since we worked together for the
>preparation of the previous draft.
>
>MAJOR POINTS
>
>1. Modify the definition of P-IDU and replace sig_token by token

(...stuff deleted...)

>The "sig_token" is used if Protect_Options is clear sign_only. This
>token also exists in the other cases and thus should be simply called
>"token".
>
>When encapsulation is NOT done and confidentiality is requested, the
>sender (and thus the receiver) has currently no way to separate the
>unencapsulated token from the M-IDU, because both are in the
>pidu_buffer. In order to achieve this a token must always be returned
>when encapsulation is not done. As a consequence the definition of the
>pidu_buffer needs to be changed. 

(...stuff deleted...)

>This means that in general a token is always be returned after some
>"protect" call when encapsulation is not requested. This problem exists
>in various places all over the document and should be corrected.

What you're asking for is accommodated in the GP calls (i.e., the
underlying mechanism can deliver an unencapsulated_token per protection
service, along with a single MIDU buffer, if it desires).  This is not
accommodated in the SE calls in a deliberate effort to keep them simple.
 The guiding principle for IDUP is as follows:  "If you want to do
complicated things, use the general-purpose calls.  If you try to put
complicated things in the simple calls, you no longer have simple
calls."

In my estimation (and I've heard implementors agree with this), having
multiple unencapsulated tokens and trying to deal with the complexity of
inputting them (perhaps in a desired order!) on the unprotection side
goes well beyond the desired simplicity of the SE calls.

>2. The GENERAL PROTECTION calls. 
>
>We have two "simple" sets of calls, one for SE and one for EV. The
>rational for having the more complex set of GENERAL PROTECTION CALLS is
>to be able to perform both SE and EV calls while processing the buffer
>once. One could expect that the GENERAL PROTECTION calls provide the
>same functionality than the SE and EV calls with buffer performances,
>since one global call would be necessary instead of a series of calls.
>This is however not the case. As an example, the EV calls allow the
>support of various types of evidences (NR of origin, creation, of
>sender, delivery, receipt, approval, etc ..., see page 24) while the
>GENERAL PROTECTION calls only allow the support of two types (PER_POO
>and PER_POD see page 16). 

Actually, the opposite is true.  The EV calls only (!) allow six types
of evidence, whereas the GP calls allow an unlimited number (the EV
calls use an INTEGER parameter, so that adding new types of evidence
requires a change to the spec., but the GP calls use an OID, so that any
number of new evidence types can be registered and used without changing
the spec.).

All we did for page 16 was to register two evidence types with IANA.
More can easily (and quickly) be registered at any time, if needed.

>Beyond this minor point that could be corrected, the BUNDLES that are
>used are rather different and the basic question is whether it would be
>possible to use some combination of the SE and EV calls to achieve a
>similar level of performance as the GENERAL PROTECTION calls. The
>performance is more related to the processing of the buffer ONCE rather
>than by the number of calls that may be needed prior to this processing.
>
>Let us first notice that the following calls, despite a different name
>are using the same parameters: IDUP_SE_Process_Buffer,
>IDUP_SE_Process_Buffer, IDUP_Protect, IDUP_Unprotect. The behaviour of
>such calls depends of the content of the env_handle and thus a single
>call, called something like IDUP_Process_Buffer would be sufficient.
>
>The basic idea is to "enrich" the env_handle using, when this is
>necessary the piggy_backing of two "simple" calls: the SE and EV calls.
>This would mean that, for example, when it is necessary to produce an
>evidence and to encrypt it, then the single_buffer calls would not be
>used, even if the buffer is short, but that the
>IDUP_SE_MultiBuffer_StartGenerate and IDUP_EV_MultiBuffer_StartGenerate
>would be called (or in the reverse order) to specify the process to be
>applied by the IDUP_Process_Buffer call. The drawback is four calls
>using the SE and EV calls + IDUP_Process_Buffer call + and an
>IDUP_End_Process_Buffer call.
>
>The benefit is that the more complex GENERAL PROTECTION calls would no
>more be needed.
>
>A minor change would be needed to accomodate that scheme. At the moment
>(see page 22) the IDUP_SE_MultiBuffer_StartProtect call is able to
>generate an initial output. When the chaining of SE and EV (or the
>reverse order) is supported, then no output should be generated at that
>time. Thus an indicator to indicate that chaining should be added in the
>Protect_Options PARAMETER BUNDLE for the SE call (see page 19) and the
>Nr_Options PARAMETER BUNDLE for the SE call (see page 25). This can
>simply be a boolean called chaining_of_operations.

I know we discussed this proposal at some length a couple of IETFs ago.
The idea of chaining the SE and EV calls so as to remove the need for
the GP calls sounds intriguing, but I think it breaks down on the
unprotection side.  How can the unprotector know which calls to use (SE
or EV), and if the answer is actually "both", how does s/he know what
order to call them in?  I don't think this can easily be solved without
significantly increasing the complexity of the SE and EV calls (i.e.,
without adding a bunch of extra parameters to control this, possibly in
conjunction with a very sophisticated "parse_token" type of call).  I
don't see a good reason to add this complexity to the simple calls when
this functionality is already accommodated in the GP calls.

Again, "If you want to do complicated things (e.g., sign AND encrypt AND
provide proof of creation AND request proof of delivery, all at the same
time), use the general-purpose calls..."

>3. Different targets for E (Encryption) and S (Signature/sealing)
>
>The IDUP_SE_SingleBuffer_Protect call (see section  2.3.2.4. on page 21)
>distinguishes between the Target_Info_E PARAMETER BUNDLE and
>Target_Info_S PARAMETER BUNDLE. This implies that the list of recipients
>may be different. The parameters are described as follows:
>
>   o  Target_Info_E PARAMETER BUNDLE, 
>      -- used if Protect_Options is encrypt_only or sign_and_encrypt 
>   o  Target_Info_S PARAMETER BUNDLE  OPTIONAL,
>      -- used only if a separate recipient list is needed for signing
>
>What about the cases for sign_then_encrypt_full, encrypt_then_sign ?
>
>We can consider the case where the list of recipients is identical for
>the requested operations, whatever they are. We can also consider the
>case where they are different (see an example below). If we want to be
>flexible we can consider separate lists for the S operation (if
>requested ) and for the E operation (if requested). We can also consider
>a list for the S+E operation.
>
>Maximum flexibility could be offered by having two or better three
>parameters:
>
>   o  Target_Info_S_E PARAMETER BUNDLE,
>      -- used for all protection options,
>   o  Target_Info_E PARAMETER BUNDLE,
>      -- used if Protect_Options contains encrypt (E)
>   o  Target_Info_S PARAMETER BUNDLE,
>      -- used if  Protect_Options contains signing/sealing (S)
>
>
>The example is about "peeling the orange". While all the protections can
>be done by one sender, the unprotection may be done by different
>recipients. For example if a sender has used sign_and_encrypt then a
>first receiver may first decipher and then pass the information to
>another recipient for the verification of the seal/signature. The goal
>is that both recipients can use the GSS-IDUP APIs. 
>
>When both operations are done by the same recipient, then the idu_buffer
>that is returned as an output parameter is what the sender asked to
>encrypt and integrity protect. Assuming that sign_then_encrypt_data is
>used, when the operations are done by different recipients, the question
>is what is the content of the idu_buffer that is returned to the first
>recipient as an output parameter of the unprotect call  ?
>
>It should be what the sender asked to encrypt and integrity protect,
>i.e. the idu_buffer. If so, the next recipient is unable to verify the
>integrity of that data, unless an additional token is returned as the
>result of the unprotect operation. In that case, the next question is
>whether the token itself contains the original idu_buffer or not. Some
>flag should be used to indicate whether such a token is awaited and an
>indicator should be given back to indicate whether the token contains
>the M-IDU or not.

It is exactly this sort of complication that leads me to say "no" to
what you're proposing.  All of this is accommodated perfectly well in
the GP calls (a common target list, which can be overridden by
per-service target lists if desired, along with per-service
unencapsulated tokens so that a given target can unprotect the specific
services relevant to him/her).  Trying to do this in the SE calls adds
too much complexity for these simple calls.

>Otherwise, for simplicity, should we only consider for a V1 version a
>single list of recipients ?

I'm quite happy to do this.  (In fact, originally I only had a single
list of recipients until you asked me to add a second one...  :-)

>MINOR POINTS
>
>4. Usefulness of sign_then_encrypt_data ?
>
>While I appreciate the various extensions allowing to perform encryption
>and signing/sealing in any order I have some difficulties to understand
>the benefits of the option (page 19) called : "sign, then encrypt
>plaintext (leaving signature in clear). With sign_and_encrypt or with
>encrypt_then_sign it is possible to have two different sets of targets
>for the verification of the signature and the decipherment. With
>encrypt_then_sign, it is possible to verify the signature/seal without
>decrypting the data. With sign_then_encrypt_data in order to be able to
>verify the signature it is necessary to decrypt first the data. This
>means that the operation has to be done by the same targets. What is the
>value of having such an option which seems to limit the generality of
>the calls, since all the other calls may have two different sets of
>targets (note: the restriction noticed here is not mentioned in the
>document). Unless there is some good reason for keeping this option, I
>would propose to suppress it.

This option was included simply to accommodate some existing protection
mechanisms.  For example, if you encrypt and sign in PEM, the data is
encrypted and the signature remains in the clear in the header.
Similarly, if you encrypt and sign in S/MIME, the data is encrypted and
the signature remains in the clear in the message structure (see
SignedAndEnvelopedData in PKCS #7).

I think there *is* good reason for keeping this option.

>5. Suppression of Non-repudiation of Retrieval ?
>
>Although I have been in the past advocating the support of
>"Non-repudiation of Retrieval" I wonder whether the APIs really allow
>the support of such case. The current paradigm is that a evidence is
>transmitted between A and B. Thus the evidence is either generated by A
>or B. Non-repudiation of Retrieval is the case where an evidence is
>returned by the messaging system testifying that the message from A was
>withdrawn from the message store by B. Since three parties are involved
>(instead of two) I wonder how this case can be supported using the
>current parameters. I would think that that case should be deleted.

I don't immediately see why you think the API doesn't handle this case,
but that doesn't matter.  If you want the case deleted, I can delete it.
 (I haven't heard anyone else mention that they want non-repudiation of
retrieval.)

>6. Reason for idu_type_string ?
>
>The idu_type_string is not explained. What is the rational for adding
>this parameter and what is its value ?
>
>7. Reason for pidu_type_string ?
>
>The pidu_type_string is not explained. What is the rational for adding
>this parameter and what is its value ?

Page 19 says that idu_type_string gives the type of the IDU (e.g.,
"data", or MIME type, or whatever).  These parameters are there to give
information about the IDU or PIDU (if this is desired and if this would
be helpful).  

As an example, if the underlying mechanism is PKCS #7 (in support of
S/MIME messaging), idu_type_string might be "data" (on input to the
protection call) and pidu_type_string might be "application/pkcs7-mime"
(on output from the protection call).  Having this information passed
across the API might make it easier for a calling application to
actually protect or unprotect a message using S/MIME without having to
know too many details about the underlying mechanism.

>8. On page 17 in IDUP_Inquire_Env (2.2.4.) 
>
>   o  policy OBJECT IDENTIFIER, 
>      -- the policy used in this env.
>   o  policy_time  INTEGER, 
>      -- time at which the policy rules came into effect
>
>should be replaced by EnvironmentPolicies (see page 14).

You're right  --  I missed this.

Denis, as always, thank you for your comments.  I appreciate your
reading the draft so carefully.

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 14 Nov 1997 17:16:58 -0800

Carlisle,

I have been disappointed by the small number of responses that we got
from the last call. We only got three sets of comments, from John Linn
(who read the document in detail), Graham Bland (one question on the C
binding) and Martin Rex (who had not read the document in detail) and; a
response from Bob Blackley pointing to an OMG document.

Nevertheless, I would like to comment your E-mail and highlight the
points where we still have different opinions.  :-(

I am making some proposals that could help for finding a compromise.

> complicated things in the simple calls, you no longer have simple

The text currently defined the SE calls as follows:

   The "SE" group of calls provides a very simple, high-level 
   interface to underlying IDUP mechanisms when application developers 
   need access only to signature and encryption protection/unprotection 
   services.  It includes both the single-buffer and multiple-buffer IDU 
   cases and can be used for signing only, encrypting only, signing and 
   encrypting (in either order, and with or without visibility of the 
   resulting signature), and "clear signing" (where the data is not 
   modified in any way and the signature itself is returned 
   (unencapsulated) as a separate item).

>From that definition the restriction you mention is not visible: it
would mean that the SE calls can only encapsulate the data. Are there
other "hidden" restrictions ? 

I still think that the GP calls may be a killer for IDUP. As a
comparison, many people find the GSS-API calls complicated (and they are
right !). The IDUP GP calls are one order of magnitude more complicated.
I still think that with some minor changes, the GP calls can be fully
avoided.

> goes well beyond the desired simplicity of the SE calls.

The (simple ?) SE calls may well be used in that case. Creating double
encapsulation is simple, making one (or even two) SE call(s).
Decapsulation is more difficult. I would think that some extension to
the IDUP_Get_token_details call would be needed. That call would then
tell you what kind of unprotection should be attempted. Four calls would
allow you to make two separate decapsulations (even by two different
receivers). You would call in sequence twice IDUP_Get_token_details and
e.g. IDUP_SE_SingleBuffer_Protect. 

> number of new evidence types can be registered and used without changing

We could also use an OID for the EV calls and register the OIDs by IANA.
This is a good suggestion.

> order to call them in?  

I would assume that using the IDUP_Get_token_details call (with a minor
addition) would solve the case. Returning the OIDs applicable for the
protection made by the SE call (if any) and made by the EV call (if
any). At least one has to be present ! Instead of returning an ordered
sequence of OIDs, in order to handle the case of double protection (e.g.
EV + SE) it would be better to have a two bits indicator to indicate the
ordering of the operations. 

>                       I don't think this can easily be solved without

The proposal hereabove only mandates a small change for the
IDUP_Get_token_details call which is in fact a more elaborated
parse_token call. It would be too bad to be close to a solution and let
it go by.

> list of recipients until you asked me to add a second one...  :-)

Different targets for E and S would then mean that two calls are needed.
Saying that better performance can only be obtained using the GP calls
means that the choice is between simplicity and two calls or complexity
and one call. If performance is not too bad in practice, my choice is
already made ... :-)

> I think there *is* good reason for keeping this option.

Fine. I have no problem if we mention that unprotection of this type of
protection can only be done by the same recipient.

>  (I haven't heard anyone else mention that they want non-repudiation of

So let us suppress it.

> know too many details about the underlying mechanism.

I understand the benefits of the pidu_type_string on output but have
more difficulties to understand the benefits of idu_type_string on input
to the protection call. Could you elaborate ?

> reading the draft so carefully.

I take the opportunity to comment on the response from Carlisle from
November the 4 th.

>> Per sec. 2.2.2, PolicyAndTime structure, is an expiration time 
>> appropriate in addition to an effectivity time? 

> Good question!  I got this structure from Denis; perhaps he can
> comment...

The structure is as follows:

PolicyAndTime ::= SEQUENCE {
      policy             OBJECT IDENTIFIER,
      -- this environment-level policy identifier is separate from 
      -- the policy provisions connected with credentials, if they exist 
      time               INTEGER
      -- on input:  the policy rules available at the specified time 
      -- on output: the time at which the policy rules came into effect
      -- (defined to be the number of seconds elapsed since midnight,
      -- January 1, 1970, coordinated universal time);
   }

The idea is when a policy is defined, it is unknown when it will be
changed. So adding an expiry time is not along this idea.

>>Per secs. 2.4.1-2.4.2 (IDUP_Form_Complete_PIDU), this is an interesting 
>>facility.  I suspect that the usage of the term "complete" as defined 
>>here (rendering self-sufficient for purposes of verification and 
>>unprotection, vs. creation of an intact, self-consistent object) may be 
>>surprising to readers; if this is covered in the [ISO/IEC] or other 
>>available citation, it might be worth citing it here.  

The term "complete" is used in the document from the OMG which has ben
pointed out by Bob Blackley.

>>                                                I've a question: 
>>if this call completes successfully, is the result presumed to be 
>>unprotectable by any entity or, if not, is there a specified means for 
>>identifying which entities are to be able to perform the unprotection 
>>operation?

>Again, I'll let Denis comment on this one (since he convinced me to add
>this call to the spec.).  My understanding (with respect to your last
>sentence above) is that a "complete" evidence token should be
>unprotectable by any entity.  [Denis can correct me if this is wrong.]

Not exactly. The verifier must have the right credentials and support
the security policy.

I hope this addresses the issues, but does not close the debate.

Regards,

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