[KEYPROV] Protocol merge options

["Doherty, Andrea" <adoherty at rsasecurity.com>]

All,
During the IETF-68 meeting, Mingliang and I presented options for
merging three explicit DSKPP capabilities into CT-KIP (ref. slides 5-8
in http://www3.ietf.org/proceedings/07mar/slides/keyprov-0/sld1.htm).
Before creating a converged protocol specification, there are open
issues that require discussion and resolution (noted in Slide 10 of
reference above).  

I'll present two of those issues here to stimulate discussion:
1. Guiding principle for strongly typing request and response parameters
	a. Avoid use of "any" types if a strong type declaration is
possible
		PROS:  
*	"any" makes schema validation and code automation difficult.  
*	Payload is currently a generic type, which will make interop
hard because the schema cannot specify it while such information may be
specified through a profile.
	   CONS: 
*	The "any" type gives flexibility (alternatively, the protocol
will be less flexible and less general if strong type declarations are
enforced)
*	CT-KIP already uses "processContents=strict" to ensure a schema
is in place. 
*	"any" is effectively only used in CT-KIP for the payload 
	b. How would can future extensibility for the payload type be
provided without "any"?

2. Keep the core protocol simple and flexible, allowing organizations to
define their own extensions
	a. One suggestion was to reserve protocol extensions for
non-standard features or provider specific information.  For example,
since payload is used in core protocol, a proposal is to have the
request and response payload explictly declared as part of the standard
body instead of using an extension.
	  PROS:  This is one option for addressing the interoperability
concern.
	  CONS:  
*	Extensions do give flexibility.  For example, consider their
well-known usage with X.509.
*	There are no "critical" extensions in CT-KIP.
	b. A better way to ensure interoperability could be to extend
the algorithms and capabilities negotiation between the client and
server to include the payload format.

I invite you to comment on the above.
Andrea

_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www1.ietf.org/mailman/listinfo/keyprov