peter van der Stok <[email protected]> wrote: > thanks for the examples. During IETF98, I was the one to speak up in > favour of #pkcs7; One reason only: It is transported by EST that is > used by BRSKI. All the code is already present. Doing JWS/COSE or > JWT/CWT needs additional code. I am sensitive to the payload size > argument though.
I disagree with your argument.
a) it's not TLS even if TLS has to do many similar things. The TLS data
packet/frame format is not just a series of PKCS7 payloads...
So for many implementers, it means reaching down into their PKIX library
and learning new things. For some, this may mean switching TLS libraries.
There is work there for the developers.
{I've been down this path, which is how I produced the PKCS7 object Max
decoded}
Also, if on the client, one has an ASN1-free (or very lite) RPK TLS
implementation, I think that one can implement BRSKI while short-cutting
much of the ASN1 parsing that EST appears to need.
b) if you replace DTLS with OSCOAP, then the argument goes in the other
direction.
c) On the Registrar level, the TLS may well be done in the framework, or
in an entirely different process [That in itself is a challenge].
This is because the TLS is done at the web load balancer level, while
the application code runs inside an application code (django, rails,
j2ee, node.js) framework.
d) Ditto for the MASA.
> But, suppose the JWS or JWT is adopted to reduce the payload, where
> will the optimizations stop? Will you envisage to optimize the EST
> payloads as well?
Not in BRSKI as produced by ANIMA.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
