How about one spec with two implementation profiles? WOES-P MUST implement PKIX key handling. WOES-R MUST implement raw key handling.
The reason I think we need both is that the WOES-R mechanism is going to be much more appropriate for the applications for which self-signed certs are generally used. [I really can't see what benefit a self signed cert provides over a raw key for any application. All you have is proof that the holder of the key created a self-signed cert.] So in my application I am going to want a stack that supports certs for the Internet trust aspects and a stack that supports raw key for the handheld device aspects. I don't want to implement the raw key in the Internet request side of things and I definitely don't want to implement the cert stuff in the handheld device. Mobile phones come with PKIX libraries but thermocouple driver chips don't .
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
