The reason I abandonded that line was that you told me about your difficulties clearing the IPR minefield in a two pass protocol like XKMS.
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Saturday, November 18, 2006 9:11 PM
> To: Arshad Noor
> Cc: Hallam-Baker, Phillip; June Leung; ken@adler.net;
> ietf-keyprov@safehaus.org; Terwilliger, Ann; John Messing;
> oasis-charter-discuss@lists.oasis-open.org; Davi Ottenheimer
> Subject: Re: [Ietf-keyprov] Re: [oasis-charter-discuss] EKMI
>
>
> I guess this isn't quite the right list, but since I didn't start
> it:-)
>
> The only reason I can think of to not extend xkms to
> encompass symmetric key management is not-invented-here.
>
> I'd be quite interested in knowing why that's wrong, and
> slightly interested in whether or not oasis has acquired
> enough sophistication to make a considered decision rather
> than simply do whatever N members want.
>
> To be clear: I think keyprov has a clear scope though of
> course it could go wrong if it crossed over into emu or (the
> now dead) sacred territory. Ekmi doesn't make much sense to
> me fwiw, extending xkms does.
>
> S.
>
> Arshad Noor wrote:
> > Phillip,
> >
> > I have reviewed these Internet-Drafts (I-D) that have been
> published
> > so far:
> >
> >
> http://www.ietf.org/internet-drafts/draft-vassilev-portable-symmetric-
> > key-container-02.txt
> >
> >
> http://www.ietf.org/internet-drafts/draft-pei-dynamic-symkey-prov-prot
> > ocol-01.txt
> >
> >
> > and believe the goals of the KEYPROV IETF WG and the
> EKMI-TC are quite
> > different.
> >
> > KEYPROV is targeting a protocol for provisioning credentials that,
> > amongst other meta-data, consist of "shared secrets". These
> > *credential-secrets* (referred to as symmetric keys in the
> I-D's) are
> > used for primarily authenticating resources against validating
> > systems.
> >
> > The EKMI-TC is targeting a protocol - Symmetric Key Services Markup
> > Language (SKSML) - for the life-cycle management (provisioning,
> > escrow, recovery, caching, destruction, etc.) of *symmetric
> encryption
> > keys* (such as 3DES, AES, etc.). These keys are used for
> encryption
> > of business data and not for authentication.
> >
> > The confusion between the WG and TC charters arises because of the
> > industry's (sometimes misguided) notion for referring to
> the "shared
> > secrets" of authentication credentials as "symmetric keys"
> - which is
> > similar to the term used by cryptographers when referring to
> > encryption/decryption keys used with symmetric ciphers.
> >
> > In addition, the use of such algorithms (3DES, AES) and symmetric-
> > encryption keys by the KEYPROV protocols to protect the "shared
> > credential secret" during provisioning, adds to the confusion.
> > Some might be misled into thinking that 3DES/AES keys are being
> > provisioned by the Provisioning System for general use by business
> > applications, as opposed to the use of those symmetric
> encryption keys
> > by the Provisioning System and the Credential Container for
> securely
> > transporting the credential-secret between the two.
> >
> > (Think of SKSML as the protocol that *might* be used by the
> > implementers of a KEYPROV-based Provisioning System, to acquire
> > symmetric encryption keys from a centralized Symmetric Key Sevices
> > server, rather than generating one itself. The
> implementers might do
> > this if there is a need for long-lived symmetric-encryption key
> > management rather than just for the transient need during the
> > credential-provisioning process).
> >
> > Given the goals and the details in the I-D's, what is misleading,
> > consequently, are the terms in use for the WG and the I-D's. More
> > appropriate terms might have been "CREDPROV", "Portable Credential
> > Container" and "Dynamic Credential Provisioning Protocol"
> for the WG
> > and the I-D's respectively.
> >
> > If the WG is wedded to the name and terms in the I-D, I would
> > encourage a paragraph or two in the charter and the Drafts, that
> > articulates the difference between the "credential-secrets"
> > provisioned through the protocols in the I-D's, and symmetric
> > encryption keys such as DES, 3DES and AES used for
> encryption of data
> > like social-security numbers, credit-card numbers, etc.
> > If we are agreed on my understanding of the KEYPROV goals, it is
> > almost certain that the documentation produced by the EKMI-TC will
> > highlight this difference.
> >
> > While XKMS is more closer to the focus of the SKSML, given
> that XKMS
> > was architected on the premise of provisioning asymmetric
> keys, trying
> > to extend XKMS to accomodate symmetric-encryption keys
> would be akin
> > to hammering a round peg into a square hole - while it can
> be done, it
> > may not look pretty and might become cumbersome to implementers who
> > wish to focus on only one or the other form of
> key-management. There
> > is nothing to prevent an implementer from implementing both
> protocols
> > in a single application if two distinct libraries took care of the
> > mechanics; most applications do this today rather than try to
> > shoe-horn every need into a single protocol.
> >
> > SAML, once again, is focused more on authentication rather
> than on a
> > life-cycle management protocol for symmetric-encryption
> keys; as such,
> > I see no overlap.
> >
> > I trust this addresses the questions raised. If I have mis-
> > understood the I-D's, and it was indeed, the KEYPROV WG's
> intention to
> > provision and manage symmetric encryption keys, please
> point me to the
> > relevant sections of the I-D that focuses on that. I will re-read
> > those sections more carefully and respond again.
> >
> > Thanks.
> >
> > Arshad Noor
> > StrongAuth, Inc.
> >
> > Hallam-Baker, Phillip wrote:
> >> In addition to the issue raised re XKMS and SAML I would
> like to make
> >> the members of this group aware of KEYPROV a group proposed to do
> >> similar work that has already begun the chatering process
> in the IETF.
> >> A BOF was held last week and a charter is currently being
> discussed
> >> on the mailing list:
> >>
> >> To join the mailing list:
> >>
> >> _http://www.safehaus.org/mailman/listinfo/ietf-keyprov_
> >>
> >>
> >> Provisional draft charter:
> >>
> >> Current developments in inter-domain Shared Symmetric Key
> tokens and
> >> inter-domain use of Kerberos have highlighted the need for
> a standard
> >> protocol for provisioning symmetric keys.
> >>
> >> The need for provisioning protocols in PKI architectures has been
> >> recognized for some time. Although the existence and
> architecture of
> >> these protocols provides a feasibility proof for the KEYPROV,
> >> assumptions built into these protocols make them inapplicable to
> >> symmetric keys.
> >>
> >> In particular the ability to provision symmetric keys and
> associated
> >> attributes dynamically to already issued devices such as
> cell phones
> >> and USB drives is highly desirable. The working group will develop
> >> the necessary protocols and data formats required to support
> >> provisioning and management of symmetric key
> authentication tokens,
> >> both proprietary and standards based.
> >>
> >> Deliverables:
> >>
> >> * Requirements and use cases
> >> * Protocol specification
> >> * Key Container specification
> >
> > _______________________________________________
> > Ietf-keyprov mailing list
> > Ietf-keyprov@safehaus.org
> > http://www.safehaus.org/mailman/listinfo/ietf-keyprov
> >
>
>
>