The document is currently intended for standards track publication. But
both the abstract and the introduction mention "describes a service".
You don't describe a standards specification. You define it? Moreover, I
find the entire tone of the document to be somewhat lacking for a
standards
Hi Michael,
I guess the question you are asking is: what is the benefit of adding the
overhead of EAP. For EAP-TLS, you could directly use TLS. For EAP-pwd (which is
a PAKE) one could use any PAKE without the EAP encapsulation overhead?
Is your concern only in the context of IoT or do you
Hi ACE,
I guess EMU is happy to see new deployments and uses of EAP. I think ACE is
better suited for taking on this work if there is interest. EMU primarily deals
with the base EAP protocol and various EAP authentication methods. We can
obviously help with reviewing the document later on.
I
I am interested in working on this draft and I support its adoption as a
working group item.
--Mohit
On 11/19/19 4:44 PM, Daniel Migault wrote:
Dear working group,
As mentioned during the ACE meeting, this mail starts a call for adoption for
draft-palombini-ace-coap-pubsub-profile. Please
is not
supported on the endpoint, the keypairs could be reprovisioned more
often than the traditional cert lifetime as the server-side key gen
transaction does not incur significant workload to the endpoint itself.
Rgs,
Panos
*From:*Mohit Sethi [mailto:mohit.m.se...@ericsson.com]
*Sent
Hi Panos,
How do you intend to use these server generated keys once they are
provisioned onto the device?
--Mohit
On 05/14/2018 04:58 PM, Panos Kampanakis (pkampana) wrote:
Hi Hannes,
To address your question about server-side key gen, below is the
explanation we have put in the draft
Hi ACE folks,
Rene has a draft in LWIG that describes how to use P-256 and Ed25519
with the same underlying implementation:
https://tools.ietf.org/html/draft-struik-lwig-curve-representations-00
Rene will be presenting it in LWIG on Wednesday at 15:20 London time.
Your input is appreciated.
Hi Mike
At least with our measurements on an 8-bit microprocessor platform,
1024-bit RSA exponentiation was extremely slow. Please have a look at
Table 1:
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01
Also, a lot of research in the crypto community is now on faster and
more
know how well that works.
Ciao
Hannes
On 07/25/2016 06:36 PM, Mohit Sethi wrote:
Hi
A quick comment. Developers often end up using
things/protocols/technologies which were not
designed/developed/specified for their use-case. I could definitely see
some IoT startup building a solution
