I don't believe any of my desirements justifies holding up publication.
Practically speaking, I'm most interested in the disconnected case. It
should also be the easiest to test thoroughly. I also believe the draft is
good enough for this case. I would very much like to see client code
Greg == Greg Hudson ghud...@mit.edu writes:
87
Greg On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com wrote:
I had always thought the same way as Sam, that clients would be
required to implement all of the options since there appears to
be no other way for them to
My take as an individual is that most of the people who have read the
draft and commented here read it the same way. It's up to the AD to
decide if things are clear enough but I'm not pushing for any specific
change and would be happy if no change were made on this point. I would
not push back
Actually, I have a question about interoperability here.
It's my assumption that a client of this specification needs to
implement basically all the options:
* encrypted OTP values and values used for key derivation *
separate pins and pins that are
On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com wrote:
I had always thought the same way as Sam, that clients would be
required to implement all of the options since there appears to be no
other way for them to support different disconnected token types. The
specification was
Greg == Greg Hudson ghud...@mit.edu writes:
87
Greg On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com
wrote:
I had always thought the same way as Sam, that clients would be
required to implement all of the options since there appears to
be no other way for them
On Aug 19, 2011, at 7:48 AM, Sam Hartman wrote:
Greg == Greg Hudson ghud...@mit.edu writes:
87
Greg On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com wrote:
I had always thought the same way as Sam, that clients would be
required to implement all of the options since there
Simon == Simon Josefsson si...@josefsson.org writes:
Simon Sam Hartman hartmans-i...@mit.edu writes:
Actually, I have a question about interoperability here.
It's my assumption that a client of this specification needs to
implement basically all the options:
*
