Subject: Re: IDUP-GSS-API...

From: Bob Blakley <[email-masked]>
Date: Mon, 17 Nov 1997 13:35:54 -0500

Hmmm,  looks like our Internet mailer stripped off all my identifying
information when I first posted this
note.  I'm restoring it here; the attached text is indeed from me.  Apologies,

--bob

Bob Blakley
IBM Lead Security Architect
Voice: +1 (512) 838-8133
Fax:    +1 (512) 838-0156
Post:    11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
Internet: [email-masked]

---------------------- Forwarded by Bob Blakley/Austin/IBM on 11/17/97 12:22 PM
---------------------------

        SMTP4@IINUS1
        11/14/97 05:38 PM
Please respond to SMTP4@IINUS1 @ internet

To: [email-masked]@us.ibm.com @ internet
cc: David Hemsath/Endicott/IBM@ibmus, Ivan Milman/Austin/IBM@ibmus, Anthony
Nadalin/Austin/IBM@ibmus, "CN=Ellen
McDermott/OU=CAM/O=Lotus@[email-masked]"@internet, "CN=Tim
Lawson/OU=CAM/O=Lotus@[email-masked]"@internet, "CN=Maryann
Hondo/OU=CAM/O=Lotus@[email-masked]"@internet
Subject: Re: IDUP-GSS-API...

Denis has shamed me into commenting just a little bit.  He writes:

>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.

I don't find the GSS calls that complicated, but I've given up on the argument
because Denis is right: everyone thinks they're very hard to use.
IDUP is actually a much *better* model in general than GSS (because it
doesn't tie security state to communications state) but it will fail
completely if it isn't seen to be simpler than GSS.  I've been hearing a LOT
of requirements for a simple, high-level security API lately.

>... 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.

I like the encapsulation model a LOT better than a parsing model, because
it lets programmers write code which looks like the following pseudocode

 receive-token();
 get-unprotect-parms (in_token);
 while (finished != unprotect(*in_token, *out_token, unprotect-parms))
  {
  get-unprotect-parms (out_token);
  strcpy (in_token, out_token);
  }

without having to worry about how many times this code goes through the loop,
or what the internal structure of tokens is, or what protection has been applied
in what sequence.

>> 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 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
>> 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).
>
>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.

I agree with Denis here.

>> >3. Different targets for E (Encryption) and S (Signature/sealing)
>> >
>much deleted stuff....
>> >
>> >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.
>> >
>even more deleted stuff....
>>
>> It is exactly this sort of complication that leads me to say "no" to
>> what you're proposing.

I'm skeptical that any of this complexity will ever be used AT ALL....

>> 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).

Even in the GP calls!!

>> 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...  :-)
>
>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 *absolutely* agree here.  I say, if you want to protect for two different
targets, use two calls.  I think it's a terrible mistake to sacrifice *either*
performance *or* simplicity of the simple (single-target) case, which is
something like 100% of what's supported today, for performance of the
complicated case.

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...
>
>structure definition omitted....
>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.

Hmmm... I'm not convinced. Certainly it's not *necessarily* known when it
will be changed, but in some cases it will be known (for example one knows
when the next CRL will be issued), and even if not, it may in some cases be
useful to provide for policies which expire even if they haven't been changed.

>>>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.

For those who can't digest PDF, I've extracted the relevant tet and included
it here.  It's easier to understand with the picture which appears in the PDF
document, but this is pretty clear:

Complete Evidence

Non-repudiation evidence may have to be verified long after it is generated.
While the information necessary to verify the evidence (e.g. the public key
of the signer of the evidence, the public key of the trusted time service
used to countersign the evidence, the details of the policy under which the
evidence was generated, etc.) will ordinarilybe easily accessible at the
time the evidence is generated, that information may be difficult or impossible
to assemble a long time afterward.

The CORBA Non-repudiation Service provides facilities for incorporating all
information necessary for the verification of a piece of non-repudiation
evidence inside the evidence token itself. A token including both
non-repudiation evidence and all information necessary to verify that evidence
is said to contain "complete" evidence.

There may be policy-related limitations on the time periods during which
complete evidence may be formed. For example, Non-repudiation policy may
permit addition of the signer's public key to the evidence only after
expiration of the interval, during which the signer may permissibly declare
that key to have been compromised. Similarly, the policy may require
application
of the Trusted Time Service countersignature within a specified interval
after application of the signer's signature.

To facilitate the generation of complete evidence, the information returned
from the calls which verify evidence and request formation of complete
evidence,
includes two indicators (complete_evidence_before and complete_evidence_after)
indicating the earliest time at which complete evidence may usefully be
requested and the latest time at which complete evidence can successfully be
formed.

A call to verify_evidence before complete evidence can be formed may result in a
response declaring the evidence to be "conditionally valid." This means that the
evidence is not invalid at the current time, but a future event (e.g. the
signer
declaring his key compromised) might cause the evidence to be invalid when
complete.

form_complete_evidence() is used when the evidence token itself does not contain
all the data required for its verification, and it is anticipated that some
of the data not stored in the token may become unavailable during the interval
between generation of the evidence token and verification unless it is stored
in the token. The form_complete_evidence operation gathers the missing
information and includes it in the token so that verification can be guaranteed
to be possible at any future time.

The verify_evidence() operation returns an indicator (evid_complete), which can
be
used to determine whether the evidence contained in a token is complete. If a
token's
evidence is not complete, the token can be passed to form_complete_evidence to
complete it.

>>>                                                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.

To elaborate a bit, it's assumed when complete_evidence completes
successfully, every bit of *data* (e.g. policy data, certificate, key, and
evidence data, context data, authority identity data, etc...) necessary
to unprotect is present in the returned token.  However as Denis rightly
points out, the verifying entity must still have credentials which permit it
to perform the unprotect action and logic which permits it to run the
algorithms (cryptographic and/or policy evaluation) which need to be run
to do the verification.