From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 30 19:26:09 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15823; Thu, 30 Apr 98 19:26:09 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA00622 for cat-ietf-redist; Thu, 30 Apr 1998 18:18:49 -0400 (EDT) From: Martin Rex Message-Id: <199804302218.AAA08951@hw1464.wdf.sap-ag.de> Subject: C-Bindings alignment with rfc2078bis To: cat-ietf@MIT.EDU Date: Fri, 1 May 1998 00:18:38 +2600 (METDST) Cc: jlinn@securitydynamics.com (John Linn), John_Wray@iris.com (John Wray) Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Since we're in WG last call, I have been reading the C-Bindings draft again to make sure that we get it properly aligned with the high level document rfc2078bis so that both documents may advance together in a consistent fashion. Here's my list of pending alignments of the C-Bindings with rfc2078bis: (1) support of certain explicit names to acquire credentials in 7.2. gss_acquire_cred 7.3. gss_add_cred quoting rfc2078bis, 2.1.1: GSS_Acquire_cred call, excerpt 2nd paragraph: ... Some implementations may therefore not support the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name resulting from applying GSS_Inquire_context() to an active context, or a name resulting from applying GSS_Inquire_cred() against a credential handle corresponding to default behavior. It is important to recognize that the explicit name which is yielded by resolving a default reference may change over time, e.g., as a result of local credential element management operations outside GSS-API; once resolved, however, the value of such an explicit name will remain constant. (2) Section 7.20. gss_inquire_context Remove fatal rountine error GSS_S_CONTEXT_EXPIRED (3) Section 7.10. gss_display_name adopt the exemption case from rfc2078bis-04 in which the nametype oid returned from gss_display_name() may be GSS_C_NO_OID (mechanisms with lazy name evaluation). (4) Section 7.16. gss_import_name add the new major_status code GSS_S_BAD_MECH when importing exported names with an unrecognized mechanism oid in the generic framing. (5) ability to request context attributes integ_req_flag and conf_req_flag in 7.19. gss_init_sec_context() to accomodate recent change to rfc2078bis, resulting from spnego discussions&requirements. (6) GSS_C_NT_HOSTBASED_SERVICE oid in gssapi.h sample header file Alignment with rfc2078bis: tag this OID from the iana arc as "new, but deprecated" and put in GSS_KRB5_NT_HOSTBASED_SERVICE_NAME from MITs arc (rfc1964, section 2.1.2.) as the old and preferred OID for this purpose, we don't want to break the installed base of Kerberos5 gssapi mechanisms and others that already use MITs OID. Actually: rfc1964 indicates that GSS_C_NT_HOSTBASED_SERVICE refers to the same OID as GSS_KRB5_NT_HOSTBASED_SERVICE_NAME -- which (unfortunately) is no longer true since the assignment of the IANA-based oid... Adding a comment into the sample header file with a pointer to the gssapi high level spec section 4 may also be helpful. (7) GSS_C_NT_EXPORTED_NAME oid in gssapi.h sample header file I would suggest adding a comment to the sample header file which points to section 3.2 of the gssapi high level document. (8) indicate in 5.9.1 GSS status codes (table 5.3) that the use of GSS_S_CONTINUE_NEEDED is restricted to the security context establishment calls. We had a discussion on the mailing list (18-21 july 1997) when it was discovered that MIT Kerberos returned GSS_S_CONTINUE_NEEDED from gss_display_status. This was considered inappropriate and Theodore Ts'o proposed to add a clarifying statement into the spec. rfc2078bis discusses the use of GSS_S_CONTINUE_NEEDED in 1.2.1.1 in connection with only the security context establishment calls. (9) inappropriate usage restriction of 7.25. process_context_token The C-Bindings description of process_context_token says that it only applies to tokens emitted from gss_delete_sec_context, whereas rfc2078bis doesn't make this claim. From the list discussion that I remember, some mechanism implementors want to be able to transfer a token with an error message back from the acceptor to the initiator when security context establishment fails. For authentications with an odd number of message exchanges, the final token will be sent from initiator to acceptor. But if the final gss_accept_sec_context fails, a resulting context-level (error) token could only be processed by the initiator calling gss_process_context_token() -- since his gss_init_sec_context() had already returned GSS_S_COMPLETE and is not expected to see another token. (10) validity of context attributes when prot_ready_state is returned from 7.1. gss_accept_sec_context() and 7.19. gss_init_sec_context(). rfc2078bis correctly reflects in section 1.2.7, last paragraph the requirement(s) for prot_ready_state: "When prot_ready_state is returned TRUE, mechanisms shall also set those context service indicator flags (deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, conf_avail, integ_avail) which represent facilities confirmed, at that time, to be available on the context being established. In situations where prot_ready_state is returned before GSS_S_COMPLETE, it is possible that additional facilities may be confirmed and subsequently indicated when GSS_S_COMPLETE is returned." It is necessary for the flags to indicate only *confirmed* facilities, since when the application decides to use immediate message protection and send along (sensitive) data, the application must be able to match the context attributes against it's policy. The current C-Bindings description of the context attributes is very detailed, but specifies that all expected, not just the confirmed (i.e. guaranteed) features need to be returned. (11) pairing of major_status codes GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN with GSS_S_FAILURE for 7.1. gss_accept_sec_context and 7.19. gss_init_sec_context We had a lengthy discussion on the list of how to distinguish mandatory and advisory classification of the major_status values GSS_S_OLD_TOKEN, GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN and GSS_S_GAP_TOKEN. The resolution is basically captured in rfc2078bis, section 1.2.1.1 second paragraph: "Sequencing-related informatory major_status codes (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN) can be indicated in conjunction with either GSS_S_COMPLETE or GSS_S_FAILURE status for GSS-API per-message calls. For context establishment calls, these sequencing-related codes will be indicated only in conjunction with GSS_S_FAILURE status (never in conjunction with GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and, therefore, always correspond to fatal failures if encountered during the context establishment phase." The (content of this) paragraph should be adopted by the C-Bindings. It may also be a good idea to mention the requirement for pairing GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN with GSS_S_FAILURE for the context establishment calls in the description of these calls where the major_status values are listed. It's probably not obvious, but the code example in the C-Bindings under 7.1. gss_accept_sec_context() already requires this pairing with GSS_S_FAILURE, because it uses the macro GSS_ERROR(maj_stat) to check for a fatal error, and this macro suppresses the informatory bits GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN. (As a result, the example does not abort reliably for GSS-API v1 mechanisms.) -Martin From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 30 20:28:12 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA16865; Thu, 30 Apr 98 20:28:12 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id TAA07645 for cat-ietf-redist; Thu, 30 Apr 1998 19:34:18 -0400 (EDT) From: Martin Rex Message-Id: <199804302333.BAA09150@hw1464.wdf.sap-ag.de> Subject: C-Bindings/rfc2078bis discuss items To: cat-ietf@MIT.EDU Date: Fri, 1 May 1998 01:33:51 +2600 (METDST) Cc: jlinn@securitydynamics.com (John Linn), John_Wray@iris.com (John Wray) Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk While re-reading the C-Bindings document I discovered a few small issues that do indicate a slight inconsistency in rfc2078bis. Since we already had closure (WG last call) on the document, these issues should only be addressed when we have immediate and obvious consensus in the WG IF we need to fix anything and how. (1) permit GSS_C_NO_NAME as the return parameter "target_name" from gss_inquire_context() (on the initiator side) for an established security context IF the context was established using GSS_C_NO_NAME for target_name and mutual_req_flag=0 (i.e. target-only authentication) Note that we added the possibility to pass in a target_name of GSS_C_NO_NAME into gss_init_sec_context at the Washington D.C. IETF *with the caveat* that existing implementations will probably not support it, even for target-only authentication. Currently rfc2078bis claims that targ_name will always be valid and a mechanism name (MN) when the call returns GSS_S_COMPLETE and the open flag is TRUE. GSS_C_NO_NAME doesn't fit this claim. (2) use of incomplete security contexts for message (un)protection due to the "prot_ready_state" indicator. The current wording in both rfc2078 (section 1.2.7) says that both: message protection and message UNprotection will become available when prot_ready_state is returned by a context establishment call. I'm somewhat uncomfortable with message UNprotection being available before the security context is successfully established. Since we don't make any restrictions on the number of message protection calls an application can do at this stage, the application could theoretically exchange thousands of protected messages before completing completing security context establishment (or even skip context establishment). And what are the semantics when the security context establishment fails after messages have been unprotected and processed? It's already to late, the gssapi can not roll back application actions based on the unprotected messages. Personally, I would really appreciate if we spec'd that message UNprotection becomes available only after the local security context establishment call has returned GSS_S_COMPLETE. This should still satisfy Bob Blakley's original requirement, which triggered the inclusion of prot_ready support in 1995. (3) mech_type return value from gss_init_sec_context() (and gss_accept_sec_context()), especially when a call fails with an error. It has been mostly discussed on the CAT list around March 27th, 1997 between Marc Horowitz and John Wray for errors during gss_accept_sec_context(), but not for gss_init_sec_context(). The problem gets more complex with the presence of a negotiation mechanism, in which case the returned mech_type from the inital call to gss_init_sec_context() will differ from the mech_type on the final call. How about an alignment to both documents that says basically: whenever a context establishment call fails with a minor_error!=0 it shall return an actual_mech_type / mech_type that can be used to translate the minor_status value via gss_display_status( GSS_C_MECH_CODE, minor_status, mech_type ) This is an exception to the C-Bindings rule that says that (pointer) output parameters will be cleared when a routine returns with a fatal error. -Martin From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 30 22:33:33 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA19672; Thu, 30 Apr 98 22:33:33 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id VAA17130 for cat-ietf-redist; Thu, 30 Apr 1998 21:16:55 -0400 (EDT) Date: Thu, 30 Apr 1998 21:16:46 -0400 Message-Id: <199805010116.VAA15435@tesla-coil.MIT.EDU> To: "Linn, John" Cc: "'CAT-WG List'" From: Tom Yu Subject: gssv2-cbind-05: OM_uint32 again.... In-Reply-To: <6B5344C210C7D011835C0000F80127660121119D@exna01.securitydynamics.com> References: <6B5344C210C7D011835C0000F80127660121119D@exna01.securitydynamics.com> Precedence: bulk Sorry this is so last minute, but the discussion of this seems to have dropped for a while, and I had temporarily forgotten that I had left this unresolved. I'd like to request changes in wording with regards to the definition of OM_uint32: from 5.1: GSSAPI uses the following integer data type: OM_uint32 32-bit unsigned integer /* ...deleted... */ If the X/Open header file is not available on the platform, the GSSAPI implementation should use the smallest natural unsigned integer type that provides at least 32 bits of precision. I suggest that the word "natural" be replaced with something like "non-derived", to make it more clear that no structures or other compiler-specific oddness shall be used in defining this type. I believe the main purpose was to make it clear that the OM_uint32 type be usable within an ABI specification and that it be a type that is "natural" for use on the architecture. Then again, merely specifying "integer" is good enough with a careful interpretation of the ANSI C standard, so perhaps the word "natural" should simply be deleted. I also suggest adding the qualifier "non-narrow", though this might be the subject of some debate. The ANSI C standard specifies that an int be the integer type most natural for computation on a particular architecture. This suggests that on some platforms, passing around short int values might require some compiler specific weirdness (e.g. folding two short ints into an int?) that may hinder binary compatibility. In addition (though we probably don't care), accessing a short int might actually be more expensive on some platforms whose natural word size is 32 bits, for instance. Also, there may be problems with compiling with K&R compilers, though we may not care about those. So I guess my opinions on revisions to gssv2-cbind are: * remove the word "natural" from the above clause in 5.1 describing OM_uint32, possibly replacing with "non-derived" * possibly add "non-narrow" to the list of requirements on the type of OM_uint32 Comments? ---Tom From owner-cat-ietf@pad-thai.cam.ov.com Fri May 1 11:47:56 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA03572; Fri, 1 May 98 11:47:56 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA28348 for cat-ietf-redist; Fri, 1 May 1998 10:12:00 -0400 (EDT) Message-Id: <6B5344C210C7D011835C0000F801276601892445@exna01.securitydynamics.com> From: "Linn, John" To: cat-ietf@MIT.EDU, "'Martin.Rex@sap-ag.de'" Cc: "Linn, John" , John_Wray@iris.com Subject: RE: C-Bindings/rfc2078bis discuss items Date: Fri, 1 May 1998 10:14:08 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Thanks, Martin, for your detailed review. Here are my thoughts on the "discuss" items: > While re-reading the C-Bindings document I discovered a few small > issues that do indicate a slight inconsistency in rfc2078bis. > Since we already had closure (WG last call) on the document, > these issues should only be addressed when we have immediate and > obvious consensus in the WG IF we need to fix anything and how. > > (1) permit GSS_C_NO_NAME as the return parameter "target_name" from > gss_inquire_context() (on the initiator side) for an established > security context > IF the context was established using GSS_C_NO_NAME for target_name > and mutual_req_flag=0 (i.e. target-only authentication) > > Note that we added the possibility to pass in a target_name > of GSS_C_NO_NAME into gss_init_sec_context at the > Washington D.C. IETF *with the caveat* that existing implementations > will probably not support it, even for target-only authentication. > > Currently rfc2078bis claims that targ_name will always be valid > and a mechanism name (MN) when the call returns GSS_S_COMPLETE > and the open flag is TRUE. GSS_C_NO_NAME doesn't fit this claim. > Good point: the fairly late breaking addition of GSS_C_NO_NAME for target_name input into gss_init_sec_context() implies a need for some corresponding action on gss_inquire_context() as well. I propose the following specific response: expand gss_inquire_context's discussion of GSS_S_COMPLETE, final sentence, to indicate that not only "open" must be true but also that a context peer's name must be known in order for a name to be returned. (The description of the return name parameters already says "if returned", implying an already-existing possibility that it might not be.) Any objections? > (2) use of incomplete security contexts for message (un)protection > due to the "prot_ready_state" indicator. > > The current wording in both rfc2078 (section 1.2.7) says that > both: message protection and message UNprotection will become > available when prot_ready_state is returned by a context > establishment call. > True. The existing 2078bis text states that TRUE prot_ready_state is sufficient to enable usage not only of GSS_Wrap() and GSS_GetMIC() but also of GSS_Unwrap() and GSS_VerifyMIC(). > I'm somewhat uncomfortable with message UNprotection being > available before the security context is successfully > established. Since we don't make any restrictions on the > number of message protection calls an application can do > at this stage, the application could theoretically exchange > thousands of protected messages before completing completing > security context establishment (or even skip context establishment). > > And what are the semantics when the security context establishment > fails after messages have been unprotected and processed? It's > already to late, the gssapi can not roll back application actions > based on the unprotected messages. > I'm not sure that I see this as a problem. If the application uses per-message unprotection upon TRUE prot_ready_state before GSS_S_COMPLETE, it's doing so based on the information which is available at that point; once returned, only mech_type (I believe) is liable to change upon a later call in the context established sequence. There's already a warning that mutual authentication isn't guaranteed until GSS_S_COMPLETE, and the anonymity service is a special case of its own; applications which require services or information which aren't guaranteed until GSS_S_COMPLETE are limited in their ability to exploit the prot_ready_state optimization. > Personally, I would really appreciate if we spec'd that message > UNprotection becomes available only after the local security > context establishment call has returned GSS_S_COMPLETE. This > should still satisfy Bob Blakley's original requirement, > which triggered the inclusion of prot_ready support in 1995. > Rather than introducing a new prohibition at this point (which might be unnecessarily strict against some valid circumstances), I'd suggest instead that we assume (strengthening warnings if necessary) that applications dependent on context data unavailable before GSS_S_COMPLETE will constrain their use of the prot_ready_state facility accordingly. > (3) mech_type return value from gss_init_sec_context() (and > gss_accept_sec_context()), especially when a call fails with an error. > > It has been mostly discussed on the CAT list around March 27th, 1997 > between Marc Horowitz and John Wray for errors during > gss_accept_sec_context(), but not for gss_init_sec_context(). > > The problem gets more complex with the presence of a negotiation > mechanism, in which case the returned mech_type from the inital > call to gss_init_sec_context() will differ from the mech_type > on the final call. > > How about an alignment to both documents that says basically: > whenever a context establishment call fails with a minor_error!=0 > it shall return an actual_mech_type / mech_type that can be > used to translate the minor_status value via > gss_display_status( GSS_C_MECH_CODE, minor_status, mech_type ) > The current situation for gss_init() and gss_accept() is that mech_type must be valid on GSS_S_COMPLETE and may also be valid (though potentially changeable for future calls) along with GSS_S_CONTINUE_NEEDED. If/when an OID is returned, the caller isn't expected to release it. Can we state simply that a mech_type shall also be returned if determinable in conjunction with fatal error cases, recognizing that there can also be cases where no supported mechanism can be identified (e.g., upon GSS_S_BAD_MECH)? Would anyone object to this (or, if so, what about a recommendation rather than a requirement?)? If the mechanism isn't supported, it doesn't seem likely that an implementation would generate minor status codes corresponding to the unsupported mechanism. > This is an exception to the C-Bindings rule that says that > (pointer) output parameters will be cleared when a routine > returns with a fatal error. > > > -Martin > --jl From owner-cat-ietf@pad-thai.cam.ov.com Fri May 1 19:32:11 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA11537; Fri, 1 May 98 19:32:11 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA15312 for cat-ietf-redist; Fri, 1 May 1998 18:24:11 -0400 (EDT) From: Martin Rex Message-Id: <199805012224.AAA13732@hw1464.wdf.sap-ag.de> Subject: Cbindings issues To: cat-ietf@MIT.EDU Date: Sat, 2 May 1998 00:24:01 +0200 (METDST) Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk I forgot one alignment issue in my list: permit gss_init_sec_context() with target_name=GSS_C_NO_NAME. There's one final issue with the C-Bindings that is irritating me: The semantics of 7.26. gss_release_buffer sounds a little strange and seems to encourage unsafe programming, because it mentions twice that (only) the length field of the gss_buffer_desc will be set to zero upon successful return. Is there any good reasons against specifying that the gss_buffer_desc will be set to GSS_C_EMPTY_BUFFER, i.e. the value part of the struct will be set to NULL as well? The current wording sounds rather like this is discouraged. I strongly suggest that we augment the description and explicitly recommend to clear the value part as well. An application may dereference the pointer accidentally due to a bug, and because of the way malloc()/free() is usually implemented such a bug doesn't always show up immediately. On the other hand, detecting a zero-pointer dereference may be as simple as a compiler switch these days (if not done automatically). I have a related concern about the other gss_release_* calls. I would really like to see an explicit recommendation to clear the handles / pointer on successful return added to the descriptions of: 7.27. gss_release_cred() 7.28. gss_release_name() 7.29. gss_release_oid_set() I assume that it is actually an implementation practice to clear these handles/pointers and the value-part of gss_buffer_desc! -Martin From owner-cat-ietf@pad-thai.cam.ov.com Sat May 2 12:29:42 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA29097; Sat, 2 May 98 12:29:42 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA22237 for cat-ietf-redist; Sat, 2 May 1998 11:54:40 -0400 (EDT) From: Martin Rex Message-Id: <199805021554.RAA17519@hw1464.wdf.sap-ag.de> Subject: Re: gssv2-cbind-05: OM_uint32 again.... To: tlyu@MIT.EDU (Tom Yu) Date: Sat, 2 May 1998 17:54:17 +0200 (METDST) Cc: cat-ietf@MIT.EDU In-Reply-To: <199805010116.VAA15435@tesla-coil.MIT.EDU> from "Tom Yu" at Apr 30, 98 09:16:46 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Tom Yu wrote: > > from 5.1: > GSSAPI uses the following integer data type: > > OM_uint32 32-bit unsigned integer > > /* ...deleted... */ > If the X/Open header file is not available on the platform, > the GSSAPI implementation should use the smallest natural unsigned > integer type that provides at least 32 bits of precision. > > So I guess my opinions on revisions to gssv2-cbind are: > > * remove the word "natural" from the above clause in 5.1 describing > OM_uint32, possibly replacing with "non-derived" > > * possibly add "non-narrow" to the list of requirements on the type of > OM_uint32 > > Comments? I'm somewhat uncomfortable with both "non-narrow" and "non-derived". Currently I don't know what either of these words mean, I will have to look them up in the ANSI-C spec when I get back to the office on Monday. I see the current expression "smallest natural unsigned integer" to be a common-sense hint for choosing: unsigned long on 16-bit platforms unsigned int on 32-bit and 64-bit platforms and it is a SHOULD, not a must! And to me, it is perfectly clear like it is. Do you have an example where a platform has such an intriguing non-standard type that an implementer would be tempted to use instead? (Such a different selection would even be valid -- the current spec doesn't *mandate* commen-sense for this choice...) If for some weird reason an implementor did select a very strange and platform- or compiler-specific type instead, then in order to obtain binary compatibility, you want to REALLY make sure that all other aspects mentioned in Appendix A of the C-Bindings are matching as well. You shouldn't attempt binary compatibility without a full ABI spec! One of the possibilities to make a less platform-dependent header file might be (although it may not cover *all* possible situations): #include #if USHRT_MAX >= 0xFFFFFFFFul # define GSS_SIZEOF_SHORT 4 #else # define GSS_SIZEOF_SHORT 2 #endif #if UINT_MAX >= 0xFFFFFFFFul # define GSS_SIZEOF_INT 4 #else # define GSS_SIZEOF_INT 2 #endif #if ULONG_MAX > 0xFFFFFFFFul # define GSS_SIZEOF_LONG 8 #else # define GSS_SIZEOF_LONG 4 #endif if (GSS_SIZEOF_SHORT == 4) typedef unsigned short gss_uint32; #elif (GSS_SIZEOF_INT == 4) typedef unsigned int gss_uint32; #elif (GSS_SIZEOF_LONG == 4) typedef unsigned long gss_uint32; #endif -Martin From owner-cat-ietf@pad-thai.cam.ov.com Mon May 4 10:33:26 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA16855; Mon, 4 May 98 10:33:26 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA29001 for cat-ietf-redist; Mon, 4 May 1998 09:14:58 -0400 (EDT) Message-Id: <199805041314.JAA23956@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-idup-gss-11.txt Date: Mon, 04 May 1998 09:14:46 -0400 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) Author(s) : C. Adams Filename : draft-ietf-cat-idup-gss-11.txt Pages : 62 Date : 01-May-98 The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated 'receivers' of the data unit. Thus, it is suitable for applications such as secure electronic mail where data needs to be protected without any on-line connection with the intended recipient(s) of that data. The protection offered by IDUP includes services such as data origin authentication with data integrity, data confidentiality with data integrity, and support for non-repudiation services. Subsequent to being protected, the data unit can be transferred to the recipient(s) - or to an archive - perhaps to be processed ('unprotected') only days or years later. Throughout the remainder of this document, the 'unit' of data described in the above paragraph will be referred to as an IDU (Independent Data Unit). The IDU can be of any size (the application may, if it wishes, split the IDU into pieces and have the protection computed a piece at a time, but the resulting protection token applies to the entire IDU). However, the primary characteristic of an IDU is that it represents a stand-alone unit of data whose protection is entirely independent of any other unit of data. If an application protects several IDUs and sends them all to a single receiver, the IDUs may be unprotected by that receiver in any order over any time span; no logical connection of any kind is implied by the protection process itself. As with RFC-2078, this IDUP-GSS-API definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source- level portability of applications to different environments. This specification Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-idup-gss-11.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-idup-gss-11.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-idup-gss-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980504085930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-idup-gss-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-idup-gss-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980504085930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Tue May 5 09:32:00 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA11207; Tue, 5 May 98 09:32:00 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id HAA03124 for cat-ietf-redist; Tue, 5 May 1998 07:35:14 -0400 (EDT) Message-Id: <354F7812.65B5@bull.net> Date: Tue, 05 May 1998 13:35:30 -0700 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: Carlisle Adams Cc: "'CAT-WG List'" Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Carlisle, Thank you for posting the revision 11. > I've seen three things (all small) that, if changed, will make all > interested parties happy with the document -- at least that's my sense of > the e-mails I've read. > > 1) Johan's comments about bad_target_name. > > 2) Denis' (and Bob's) comments about role. [By the way, I agree with Bob > and slightly prefer the Boolean; is this O.K. with you Denis?] It is O.K. I skimmed through the document and I noticed three minor problems: In section 2.3.2.2. on page 19 two lines before the end of the page we should have: o originator_role Originator_Role OPTIONAL, instead of: o originator_role Originator_Role, In the same way, in section 2.3.4.1. on page 33 three lines before the end of the page we should also have: o originator_role Originator_Role OPTIONAL, instead of: o originator_role Originator_Role, Finally, the structure: o Originator_Role PARAMETER BUNDLE, -- role in organization o domain_name INTERNAL NAME OPTIONAL, o role PRINTABLE STRING, o role_info_is_authenticated BOOLEAN -- TRUE if info. is authenticated (e.g., inside a cert.) which is fine, is only described in the section about the GP calls, but not the SE and EV calls. Shouldn't we duplicate that structure in these sections ? Regards, Denis > 3) Graham's comments on IDU length (I have March 25th in my notes here, but > I can't remember offhand if that was a private mail or a message to the > list. In any case, it echoed one of the items in his original posting to > the list). > > I will fix/add all three and re-issue as soon as possible (i.e., within a > few days). Thanks to everyone for the input! > > -------------------------------------------- > Carlisle Adams > Entrust Technologies > cadams@entrust.com > -------------------------------------------- -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net 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 From owner-cat-ietf@pad-thai.cam.ov.com Tue May 5 12:34:49 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA14352; Tue, 5 May 98 12:34:49 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA24150 for cat-ietf-redist; Tue, 5 May 1998 11:19:57 -0400 (EDT) Message-Id: <354F2D33.674A499F@sectra.se> Date: Tue, 05 May 1998 17:16:04 +0200 From: "Johan Otterstrvm" X-Mailer: Mozilla 4.01 [en] (WinNT; I) Mime-Version: 1.0 To: cat Subject: Bad target names X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 X-Mime-Autoconverted: from 8bit to quoted-printable by desmond.sectra.se id LAA24441 X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id LAA24148 Precedence: bulk Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by pad-thai.cam.ov.com id LAA24150 Hello, continuing my work with the IDUP-API I have a problem with the "hiding" of the bad target names in the target info. It seems to me that a more straighforward solution is to use a SET OF INTERNAL NAME as input and SET OF Bad_Target_Name as output. Is there a reason to combine these two? regards /jo -- ---------------------------------------------------------------- Johan Otterstr=F6m Sectra AB Phone +46 13 23 52 46 Teknikringen 2 Telefax +46 13 21 21 85 S-583 30 Link=F6ping Mail mailto:jo@sectra.se SWEDEN WWW http://www.sectra.se ---------------------------------------------------------------- From owner-cat-ietf@pad-thai.cam.ov.com Thu May 7 17:32:10 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA10551; Thu, 7 May 98 17:32:10 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA26252 for cat-ietf-redist; Thu, 7 May 1998 16:29:34 -0400 (EDT) Date: Thu, 7 May 1998 16:29:22 -0400 Message-Id: <199805072029.QAA06141@tesla-coil.MIT.EDU> To: Martin.Rex@sap-ag.de Cc: tlyu@mit.edu (Tom Yu), cat-ietf@mit.edu From: Tom Yu Subject: Re: gssv2-cbind-05: OM_uint32 again.... In-Reply-To: <199805021554.RAA17519@hw1464.wdf.sap-ag.de> References: <199805010116.VAA15435@tesla-coil.MIT.EDU> <199805021554.RAA17519@hw1464.wdf.sap-ag.de> Precedence: bulk My main objection to this is that a short should never be used, for the reasons short ints might be inefficient, or might be tight-packed in function calls or data structures in a language-dependent way, etc. Also, there is the issue of linking with code compiled by K&R compilers, though we might not care about that. I think we can forget about "non-derived", as "integral" is probably sufficiently specific given the wording of the ANSI C spec. I was intending to exclude the use of weird things like bitfields inside structs, since structs are defined as "derived" types by ANSI C. Also, I believe that a re-reading of the ANSI C spec indicates that the wording "non-narrow" is potentially ambiguous, as the term "narrow" is never actually used in the spec to refer to types that are smaller than int. I think that we should make it explicit that an OM_uint32 shall not be a type that is smaller than the native "int" type. ---Tom From owner-cat-ietf@pad-thai.cam.ov.com Tue May 12 11:40:38 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA11456; Tue, 12 May 98 11:40:38 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA03109 for cat-ietf-redist; Tue, 12 May 1998 10:28:45 -0400 (EDT) Message-Id: From: "Linn, John" To: Carlisle Adams , "'Denis.Pinkas@bull.net'" Cc: "'CAT-WG List'" Subject: RE: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt Date: Tue, 12 May 1998 10:28:01 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Precedence: bulk It's my belief that all identified idup issues except the role question have been handled, so we're almost ready to forward to the IESG on behalf of the WG. Now looking at idup-11, however (after having been off-line last week), I'm a bit confused: Denis/Bob's original request was for a role parameter in Sec. 2.3.3.2 (for EV calls), Originator_Information. No such parameter has been included there, though there now is one in 2.3.2.2 (for SE calls), PIDU_Information and 2.3.4.1(for GP calls), Prot_Information, with associated Originator_Role definition. Is the original request for a parameter in Originator_Information now moot, or does it still apply in addition to the comments which Denis posted in the attached message? --jl > ---------- > From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net] > Reply To: Denis.Pinkas@bull.net > Sent: Tuesday, May 05, 1998 4:35 PM > To: Carlisle Adams > Cc: 'CAT-WG List' > Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt > > Carlisle, > > Thank you for posting the revision 11. > > > I've seen three things (all small) that, if changed, will make all > > interested parties happy with the document -- at least that's my sense > of > > the e-mails I've read. > > > > 1) Johan's comments about bad_target_name. > > > > 2) Denis' (and Bob's) comments about role. [By the way, I agree with > Bob > > and slightly prefer the Boolean; is this O.K. with you Denis?] > > It is O.K. I skimmed through the document and I noticed three minor > problems: > > In section 2.3.2.2. on page 19 two lines before the end of the page we > should have: > > o originator_role Originator_Role OPTIONAL, > > instead of: > > o originator_role Originator_Role, > > In the same way, in section 2.3.4.1. on page 33 three lines before the > end of the page we should also have: > > o originator_role Originator_Role OPTIONAL, > > instead of: > > o originator_role Originator_Role, > > Finally, the structure: > > o Originator_Role PARAMETER BUNDLE, -- role in organization > o domain_name INTERNAL NAME OPTIONAL, > o role PRINTABLE STRING, > o role_info_is_authenticated BOOLEAN > -- TRUE if info. is authenticated (e.g., inside a cert.) > > which is fine, is only described in the section about the GP calls, but > not the SE and EV calls. Shouldn't we duplicate that structure in these > sections ? > > Regards, > > Denis > > > 3) Graham's comments on IDU length (I have March 25th in my notes here, > but > > I can't remember offhand if that was a private mail or a message to the > > list. In any case, it echoed one of the items in his original posting > to > > the list). > > > > I will fix/add all three and re-issue as soon as possible (i.e., within > a > > few days). Thanks to everyone for the input! > > > > -------------------------------------------- > > Carlisle Adams > > Entrust Technologies > > cadams@entrust.com > > -------------------------------------------- > > -- > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > 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 > From owner-cat-ietf@pad-thai.cam.ov.com Tue May 12 12:32:23 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA12329; Tue, 12 May 98 12:32:23 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA09419 for cat-ietf-redist; Tue, 12 May 1998 11:34:27 -0400 (EDT) Message-Id: From: "Linn, John" To: "Linn, John" , "'Denis.Pinkas@bull.net'" Cc: Carlisle Adams , "'CAT-WG List'" Subject: RE: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt Date: Tue, 12 May 1998 11:33:59 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Precedence: bulk Denis, re: > I will attempt to answer your questions. > Thanks. > > It's my belief that all identified idup issues except the role question > have > > been handled, so we're almost ready to forward to the IESG on behalf of > the > > WG. Now looking at idup-11, however (after having been off-line last > week), > > I'm a bit confused: Denis/Bob's original request was for a role > parameter in > > Sec. 2.3.3.2 (for EV calls), Originator_Information. No such parameter > has > > been included there, > > In 2.3.3.2. IDUP_EV Parameters, we have: > > o Originator_Information PARAMETER BUNDLE > o token_generator_name INTERNAL NAME, > -- obtained from the credentials of the originator > -- (e.g., from its public key certificate) > o token_generator_role Originator_Role OPTIONAL, > -- (see Section 2.3.4.1) > o protection_time INTEGER OPTIONAL > > So the Originator_Role is present. In believe that the initial request > has been extended by Carlisle so that all calls now support it. > I (mis)read too quickly. My apologies. > > though there now is one in 2.3.2.2 (for SE calls), > > PIDU_Information and 2.3.4.1(for GP calls), Prot_Information, with > > associated Originator_Role definition. Is the original request for a > > parameter in Originator_Information now moot, or does it still apply in > > addition to the comments which Denis posted in the attached message? > > The remaining problem has to do with the OPTIONAL indicator that needs > to be fixed and some text to be duplicated (or clearly referenced). > OK. What's the path for closure here? --jl From owner-cat-ietf@pad-thai.cam.ov.com Tue May 12 13:27:41 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA13314; Tue, 12 May 98 13:27:41 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA08853 for cat-ietf-redist; Tue, 12 May 1998 11:28:55 -0400 (EDT) Message-Id: <3558E962.6F23@bull.net> Date: Tue, 12 May 1998 17:29:22 -0700 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: "Linn, John" Cc: Carlisle Adams , "'CAT-WG List'" Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk John, I will attempt to answer your questions. > It's my belief that all identified idup issues except the role question have > been handled, so we're almost ready to forward to the IESG on behalf of the > WG. Now looking at idup-11, however (after having been off-line last week), > I'm a bit confused: Denis/Bob's original request was for a role parameter in > Sec. 2.3.3.2 (for EV calls), Originator_Information. No such parameter has > been included there, In 2.3.3.2. IDUP_EV Parameters, we have: o Originator_Information PARAMETER BUNDLE o token_generator_name INTERNAL NAME, -- obtained from the credentials of the originator -- (e.g., from its public key certificate) o token_generator_role Originator_Role OPTIONAL, -- (see Section 2.3.4.1) o protection_time INTEGER OPTIONAL So the Originator_Role is present. In believe that the initial request has been extended by Carlisle so that all calls now support it. > though there now is one in 2.3.2.2 (for SE calls), > PIDU_Information and 2.3.4.1(for GP calls), Prot_Information, with > associated Originator_Role definition. Is the original request for a > parameter in Originator_Information now moot, or does it still apply in > addition to the comments which Denis posted in the attached message? The remaining problem has to do with the OPTIONAL indicator that needs to be fixed and some text to be duplicated (or clearly referenced). Denis > --jl > > ---------- > > From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net] > > Reply To: Denis.Pinkas@bull.net > > Sent: Tuesday, May 05, 1998 4:35 PM > > To: Carlisle Adams > > Cc: 'CAT-WG List' > > Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt > > > > Carlisle, > > > > Thank you for posting the revision 11. > > > > > I've seen three things (all small) that, if changed, will make all > > > interested parties happy with the document -- at least that's my sense > > of > > > the e-mails I've read. > > > > > > 1) Johan's comments about bad_target_name. > > > > > > 2) Denis' (and Bob's) comments about role. [By the way, I agree with > > Bob > > > and slightly prefer the Boolean; is this O.K. with you Denis?] > > > > It is O.K. I skimmed through the document and I noticed three minor > > problems: > > > > In section 2.3.2.2. on page 19 two lines before the end of the page we > > should have: > > > > o originator_role Originator_Role OPTIONAL, > > > > instead of: > > > > o originator_role Originator_Role, > > > > In the same way, in section 2.3.4.1. on page 33 three lines before the > > end of the page we should also have: > > > > o originator_role Originator_Role OPTIONAL, > > > > instead of: > > > > o originator_role Originator_Role, > > > > Finally, the structure: > > > > o Originator_Role PARAMETER BUNDLE, -- role in organization > > o domain_name INTERNAL NAME OPTIONAL, > > o role PRINTABLE STRING, > > o role_info_is_authenticated BOOLEAN > > -- TRUE if info. is authenticated (e.g., inside a cert.) > > > > which is fine, is only described in the section about the GP calls, but > > not the SE and EV calls. Shouldn't we duplicate that structure in these > > sections ? > > > > Regards, > > > > Denis > > > > > 3) Graham's comments on IDU length (I have March 25th in my notes here, > > but > > > I can't remember offhand if that was a private mail or a message to the > > > list. In any case, it echoed one of the items in his original posting > > to > > > the list). > > > > > > I will fix/add all three and re-issue as soon as possible (i.e., within > > a > > > few days). Thanks to everyone for the input! > > > > > > -------------------------------------------- > > > Carlisle Adams > > > Entrust Technologies > > > cadams@entrust.com > > > -------------------------------------------- > > > > -- > > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > > 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 > > -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net 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 From owner-cat-ietf@pad-thai.cam.ov.com Tue May 12 15:34:41 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15472; Tue, 12 May 98 15:34:41 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA29728 for cat-ietf-redist; Tue, 12 May 1998 15:02:59 -0400 (EDT) Message-Id: From: Carlisle Adams To: "'Denis.Pinkas@bull.net'" Cc: "'CAT-WG List'" Subject: RE: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt Date: Tue, 12 May 1998 14:58:51 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Precedence: bulk Hi Denis, Sorry for the long delay but I've been tied up getting the AES submission together... > ---------- > From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net] > Sent: Tuesday, May 05, 1998 4:35 PM > To: Carlisle Adams > Cc: 'CAT-WG List' > Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt > > Carlisle, > > I skimmed through the document and I noticed three minor > problems: > > In section 2.3.2.2. on page 19 two lines before the end of the page we > should have: > > o originator_role Originator_Role OPTIONAL, > > instead of: > > o originator_role Originator_Role, > > In the same way, in section 2.3.4.1. on page 33 three lines before the > end of the page we should also have: > > o originator_role Originator_Role OPTIONAL, > > instead of: > > o originator_role Originator_Role, > Parameter bundles, by definition, are already OPTIONAL. See, for example, the text on parameter bundles from page 32 (Section 2.3.4.1): "An application not wishing to use a particular bundle ... can pass NULL as the bundle "parameter"." It is therefore redundant to put "Originator_Role OPTIONAL" in the structure. This is why I left it out of the SE and GP calls. I was going to leave it out of the EV calls for the same reason, but you had specifically requested the word OPTIONAL (this discussion was in the context of evidence calls) and since it didn't hurt to put it in, I figured I'd put it there so that you would have absolutely no reason to ask for yet another revision of this document. :-) > Finally, the structure: > > o Originator_Role PARAMETER BUNDLE, -- role in organization > o domain_name INTERNAL NAME OPTIONAL, > o role PRINTABLE STRING, > o role_info_is_authenticated BOOLEAN > -- TRUE if info. is authenticated (e.g., inside a cert.) > > which is fine, is only described in the section about the GP calls, but > not the SE and EV calls. Shouldn't we duplicate that structure in these > sections ? > In your most recent note you said: >The remaining problem has to do with the OPTIONAL indicator that needs >to be fixed and some text to be duplicated (or clearly referenced). The structure *is* clearly referenced. In both the SE and EV structures (pp. 19 and 25) it says "(see Section 2.3.4.1)" right beside Originator_Role. How much clearer a reference do you want? I don't believe it is necessary to duplicate the structure in all three sections. Can we now finally move forward with this document? It really does capture all the things you wanted from this API, including your latest comments... Carlisle. From owner-cat-ietf@pad-thai.cam.ov.com Thu May 14 11:45:30 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA03080; Thu, 14 May 98 11:45:30 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA28924 for cat-ietf-redist; Thu, 14 May 1998 10:13:37 -0400 (EDT) Message-Id: From: Carlisle Adams To: cat , "'Johan Otterstrvm'" Subject: RE: Bad target names Date: Thu, 14 May 1998 10:11:05 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Precedence: bulk Hi Johan, > ---------- > From: Johan Otterstrvm[SMTP:jo@sectra.se] > Sent: Tuesday, May 05, 1998 11:16 AM > To: cat > Subject: Bad target names > > Hello, > > continuing my work with the IDUP-API I have a problem with the "hiding" > of the bad target names in the target info. It seems to me that a more > straighforward solution is to use a SET OF INTERNAL NAME as input and > SET OF Bad_Target_Name as output. Is there a reason to combine these > two? > The concept of parameter bundles has been used in this API simply to tie together parameters that are logically / conceptually related in some way. This is the case here: "target names" and "bad target names" don't *have* to be tied together (i.e., they could be separated as you suggest), but they seem so related that tying them together makes sense. For example, if a calling application wishes to sign a document (only) using IDUP, then it doesn't need the target names parameter. By extension, therefore, it doesn't need the bad target names parameter either. Parameter bundles are not used to "hide" parameters; they are used to "group" parameters. It seems to me that this particular grouping is reasonable here. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From owner-cat-ietf@pad-thai.cam.ov.com Fri May 15 09:33:24 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA25513; Fri, 15 May 98 09:33:24 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA01524 for cat-ietf-redist; Fri, 15 May 1998 08:15:25 -0400 (EDT) Message-Id: <355C3158.DD92C2E1@sectra.se> Date: Fri, 15 May 1998 14:13:12 +0200 From: "Johan Otterstrvm" X-Mailer: Mozilla 4.01 [en] (WinNT; I) Mime-Version: 1.0 To: Carlisle Adams Cc: cat Subject: Re: Bad target names X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=iso-8859-1 X-Mime-Autoconverted: from 8bit to quoted-printable by desmond.sectra.se id IAA03936 X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id IAA01522 Precedence: bulk Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by pad-thai.cam.ov.com id IAA01524 Hello again, Carlisle Adams wrote: > Hi Johan, > > > ---------- > > From: Johan Otterstrvm[SMTP:jo@sectra.se] > > Sent: Tuesday, May 05, 1998 11:16 AM > > To: cat > > Subject: Bad target names > > > > Hello, > > > > continuing my work with the IDUP-API I have a problem with the > "hiding" > > of the bad target names in the target info. It seems to me that a > more > > straighforward solution is to use a SET OF INTERNAL NAME as input > and > > SET OF Bad_Target_Name as output. Is there a reason to combine these > > > two? > > > The concept of parameter bundles has been used in this API simply to > tie > together parameters that are logically / conceptually related in some > way. > This is the case here: "target names" and "bad target names" don't > *have* > to be tied together (i.e., they could be separated as you suggest), > but they > seem so related that tying them together makes sense. For example, if > a > calling application wishes to sign a document (only) using IDUP, then > it > doesn't need the target names parameter. By extension, therefore, it > doesn't need the bad target names parameter either. > > Parameter bundles are not used to "hide" parameters; they are used to > "group" parameters. It seems to me that this particular grouping is > reasonable here. > The grouping make sence in that the bad target names are a subset of the target names but still the target names are input and bad target names are output. But as with your example there are other parameters that are not used for some cases, for example the pidu-buffer in clear-signing. If the grouping is a fact I would suggest that the parameter is in- and output. The target-info may also be changed to be a set of bad target name only (a new name would be prefered) were the names are used as input and the status as output for each name. It is not necessary to name the names twice. In any case the bad_targ_count is unnecessary since bad_target_names is a set. regards /jo -- ---------------------------------------------------------------- Johan Otterstr=F6m Sectra AB Phone +46 13 23 52 46 Teknikringen 2 Telefax +46 13 21 21 85 S-583 30 Link=F6ping Mail mailto:jo@sectra.se SWEDEN WWW http://www.sectra.se ---------------------------------------------------------------- From owner-cat-ietf@pad-thai.cam.ov.com Wed May 27 16:38:09 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA03816; Wed, 27 May 98 16:38:09 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA08960 for cat-ietf-redist; Wed, 27 May 1998 15:52:45 -0400 (EDT) Message-Id: <199805271952.TAA09256@gza-server.cam.ov.com> X-Mailer: exmh version 1.6.9 8/22/96 To: cat-ietf@cam.ov.com Subject: test3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 May 1998 15:52:24 -0400 From: "Frank D'Urso" Precedence: bulk test3 John Linn Call me From owner-cat-ietf@pad-thai.cam.ov.com Thu May 28 09:48:35 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA21915; Thu, 28 May 98 09:48:35 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA10703 for cat-ietf-redist; Thu, 28 May 1998 08:28:11 -0400 (EDT) Message-Id: From: "Linn, John" To: "'CAT-WG List'" Subject: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt Date: Thu, 28 May 1998 08:27:10 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk > Resending to the list, following some intervening mail forwarding > problems. My hope and belief is that the group is OK with idup-gss-11. > > --jl > > ---------- > From: Linn, John > Sent: Friday, May 22, 1998 8:34 AM > To: 'Denis.Pinkas@bull.net'; 'Carlisle Adams'; Linn, John > Cc: 'CAT-WG List' > Subject: RE: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt > > I'm resending the attached message from yesterday because I haven't seen a > list-addressed copy so don't know if it got lost in transit thereto. In > the interim, Carlisle provided me a correction for the discussion as I > wrote it below, reminding of the fact that bundles are optional at *all* > levels, even when nested within other bundles, so (despite the fact that > other parallel, non-bundle elements need to be tagged OPTIONAL in order to > be optional), any bundles at a particular nesting level are implicitly > optional and don't need to be so tagged. It now seems to me, therefore, > that presence/absence of an OPTIONAL tag for the Originator_Role bundle is > really a technical non-issue, though it's a minor anomaly to apply it to > some instances of Originator_Role but not others. Can we accept this and > move forward with the idup-gss-11 draft as written? > > --jl > > ---------- > From: Linn, John > Sent: Thursday, May 21, 1998 9:57 AM > To: 'Denis.Pinkas@bull.net'; 'Carlisle Adams' > Cc: 'CAT-WG List' > Subject: RE: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt > > Carlisle wrote, excerpting, in reply to Denis: > > > In section 2.3.2.2. on page 19 two lines before the end of the > page we > > should have: > > > > o originator_role Originator_Role OPTIONAL, > > > > instead of: > > > > o originator_role Originator_Role, > > > > In the same way, in section 2.3.4.1. on page 33 three lines before > the > > end of the page we should also have: > > > > o originator_role Originator_Role OPTIONAL, > > > > instead of: > > > > o originator_role Originator_Role, > > > Parameter bundles, by definition, are already OPTIONAL. See, for > example, > the text on parameter bundles from page 32 (Section 2.3.4.1): > > "An application not wishing to use a particular bundle ... > can pass NULL as the bundle "parameter"." > > It is therefore redundant to put "Originator_Role OPTIONAL" in the > structure. This is why I left it out of the SE and GP calls. I was > going > to leave it out of the EV calls for the same reason > > As I understand the situation (please correct me if I'm wrong), > there are two distinct layers of optionality here, which may not be > mutually redundant. If there's no OPTIONAL qualifier on Originator_Role > within the bundle, then it's not possible to use the bundle facility to > carry other information within that bundle (protect_options, > originator_name, protection_time, idu_information) without also using the > Originator_Role facility. Several of these items seem to have broad > applicability. Particularly given that the Originator_Role is a relatively > recent addition, it's not clear to me that its usage should necessarily > become a prerequisite for all callers wishing to make use of the bundles > within which it occurs. > > Can we now finally move forward with this document? It really does > capture > all the things you wanted from this API, including your latest > comments... > > The group is committed to recommending that IDUP move forward (with > recognized issues reconciled, consistent with process), and I believe that > we're all striving towards this goal; thanks to all for the conscientious > efforts. If the OPTIONALs were applied to Originator_Role within 2.3.2.2 > and 2.3.4.1, I believe we'd remove the last pending contentious point. I > suggest, therefore, one more reissue of the draft to add this pair of > words; upon appearance of that version, I'll plan to forward it to the > IESG on behalf of the WG. Can we all live with this? > > Carlisle. > > --jl > > > >