Re: [Anima-bootstrap] [Anima] Voucher signing method

Michael Richardson <> Wed, 26 April 2017 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91D9E12EC7F; Wed, 26 Apr 2017 08:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xLiiGNm5Lg6O; Wed, 26 Apr 2017 08:36:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0ED52130133; Wed, 26 Apr 2017 08:36:40 -0700 (PDT)
Received: from ( [IPv6:2604:8800:100:1a::2]) by (Postfix) with ESMTPS id C50EE1F8EE; Wed, 26 Apr 2017 15:36:38 +0000 (UTC)
Received: by (Postfix, from userid 179) id 79986598; Wed, 26 Apr 2017 11:36:34 -0400 (EDT)
From: Michael Richardson <>
cc: "Max Pritikin (pritikin)" <>,,
In-reply-to: <>
References: <> <>
Comments: In-reply-to peter van der Stok <> message dated "Wed, 19 Apr 2017 09:01:04 +0200."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 26 Apr 2017 11:36:34 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [Anima-bootstrap] [Anima] Voucher signing method
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2017 15:36:51 -0000

peter van der Stok <> 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

   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

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  [
]        |   ruby on rails    [

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-