Re: [KEYPROV] PROTOWRITEUPfor draft-ietf-keyprov-symmetrickeyformat-07

Siddharth,

You are right, a number of vendors have invested in what I consider
dubious product concepts like "connected OTP".

I don't see why anyone would have to wait on the standard since the
required middleware is 100% non-standard.

I.e. there is no client-side interoperability whatsoever between for example
VeriSign and RSA.  It was actually never a goal, as far as I remember.

Sorry for being negative but from my horizon KEYPROV became a very marginal
scheme which is the reason I'm pursuing entirely different paths which
may indeed one day reach OATH's to date not realized vision.

Anders

Bajaj, Siddharth wrote:
>  
> Hi Anders,
>  
> I'll beg to differ you with you - several OATH members including 
> VeriSign have implemented drafts of the online provisioning protocol in 
> their products today.
>  
> Others are waiting for this standard to be finalized so that they can 
> implement the final versions.
> Thanks,
>  
> Siddharth
> 
> ------------------------------------------------------------------------
> *From:* keyprov-bounces@ietf.org on behalf of Anders Rundgren
> *Sent:* Wed 3/3/2010 8:43 AM
> *To:* Philip Hoyer
> *Cc:* keyprov@ietf.org
> *Subject:* Re: [KEYPROV] PROTOWRITEUPfor 
> draft-ietf-keyprov-symmetrickeyformat-07
> 
> Philip Hoyer wrote:
>  > And how is that redundant to an openly discussed peer reviewed agreed
>  > IETF standard that RSA has also contributed to?
> 
> There has indeed been open discussions regarding the *content* of
> draft.  However, there has not been much open discussions regarding
> *utility* and *deployment*, something which I feel has hampered the
> entire KEYPROV effort.
> 
> Why would anybody in their right mind use on-line provisioning with
> DSKPP for discrete OTP tokens?  Isn't sort of half the value with OTP
> *getting away* from middleware?
> 
> RSA, VeriSign, Nicrosoft, IBM etc have contributed to many standards but
> not all of them have been successful in the marketplace.
> 
> Anders
> 
>  >
>  >
>  > ----- Original Message -----
>  > From: Anders Rundgren <anders.rundgren@telia.com>
>  > To: Philip Hoyer
>  > Cc: turners@ieca.com <turners@ieca.com>; keyprov@ietf.org 
> <keyprov@ietf.org>
>  > Sent: Wed Mar 03 17:10:46 2010
>  > Subject: Re: [KEYPROV] PROTO WRITEUPfor
>  > draft-ietf-keyprov-symmetrickeyformat-07
>  >
>  > Philip Hoyer wrote:
>  >  > Redundant to what exactly?
>  >
>  > I believe I elaborated that in my initial posting.
>  >
>  > RSA have had seeds distributed in XML format for ages and they work
>  > on multiple platforms including mobile phones.
>  >
>  >
>  > Anders
>  >
>  >  >
>  >  >
>  >  > ----- Original Message -----
>  >  > From: keyprov-bounces@ietf.org <keyprov-bounces@ietf.org>
>  >  > To: Sean Turner <turners@ieca.com>
>  >  > Cc: keyprov@ietf.org <keyprov@ietf.org>
>  >  > Sent: Wed Mar 03 15:54:36 2010
>  >  > Subject: Re: [KEYPROV] PROTO WRITEUPfor
>  >  > draft-ietf-keyprov-symmetrickeyformat-07
>  >  >
>  >  > Sean Turner wrote:
>  >  >  > Anders,
>  >  >  >
>  >  >  > PSKC is the mandatory to implement key package and nobody, that 
> I am
>  >  >  > aware of, is trying to change that.  The container defined in
>  >  >  > draft-ietf-keyprov-symmetrickeyformat-07 is optional to implement.
>  >  >
>  >  > I just said that it felt like a redundant solution.
>  >  >
>  >  > /anders
>  >  >
>  >  >
>  >  >  >
>  >  >  > spt
>  >  >  >
>  >  >  > Anders Rundgren wrote:
>  >  >  >> The document is great from a technical point of view.
>  >  >  >>
>  >  >  >> The utility is questionable since PSKC does the same
>  >  >  >> thing and also interopes with DSKPP.  The rationale
>  >  >  >> (which has been mentioned but not been put on paper)
>  >  >  >> "cards cannot process XML" is true but provisioning
>  >  >  >> generally relies on middleware doing the unpacking
>  >  >  >> and then through some API inserting keys and attributes
>  >  >  >> in the card.
>  >  >  >>
>  >  >  >> Creating tokens that would decipher CMS is technically
>  >  >  >> doable but there is absolutely no point with that
>  >  >  >>
>  >  >  >> In case you want to know how you can deal with XML,
>  >  >  >> secure transfer of secrets, and still keep the token
>  >  >  >> device unaware of sophisticated data structures and
>  >  >  >> public key verification you may take a peek in the
>  >  >  >> following document:
>  >  >  >>
>  >  >  >> "setPiggybackedSymmetricKey"
>  >  >  >>
>  >  >  >> http://webpki.org/papers/keygen2/sks-api-arch.pdf 
> <https://connect.verisign.com/papers/keygen2/,DanaInfo=.awfdsonFvzp+sks-api-arch.pdf>
>  >  >  >>
>  >  >  >> Anders
>  >  >  >> _______________________________________________
>  >  >  >> KEYPROV mailing list
>  >  >  >> KEYPROV@ietf.org
>  >  >  >> https://www.ietf.org/mailman/listinfo/keyprov 
> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov>
>  >  >  >>
>  >  >  >
>  >  >
>  >  > _______________________________________________
>  >  > KEYPROV mailing list
>  >  > KEYPROV@ietf.org
>  >  > https://www.ietf.org/mailman/listinfo/keyprov 
> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov>
>  >  >
>  >
> 
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov 
> <https://connect.verisign.com/mailman/listinfo/,DanaInfo=.awxyCmjzmHx1r,SSL+keyprov>
> 