[core] raza-ace-cbor-certificates

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 15 May 2019 19:59 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A061812022D for <core@ietfa.amsl.com>; Wed, 15 May 2019 12:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKXDWgSxecMe for <core@ietfa.amsl.com>; Wed, 15 May 2019 12:59:51 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6B6120147 for <core@ietf.org>; Wed, 15 May 2019 12:59:51 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D8C83826C for <core@ietf.org>; Wed, 15 May 2019 15:59:05 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id F12A9E3B; Wed, 15 May 2019 15:59:49 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EE9DAA2 for <core@ietf.org>; Wed, 15 May 2019 15:59:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: core@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 15 May 2019 15:59:49 -0400
Message-ID: <10882.1557950389@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/nUsEZ21FJoTOElLmq2I0ty6bXkM>
Subject: [core] raza-ace-cbor-certificates
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 19:59:54 -0000

If we transcode ASN.1 to CBOR rather than DER in a way that preserves the
signature, then I think we miss all opportunities to throw away the DER code.

If we can outsource this to a third party to verify, we can just throw the
DER itself to the third party, and wrap it in a RESTful COAP interface.

I see two issues with PKIX certificates:
  a) DNs never made any sense in 1980 when a company could have three
     people named John Smith, and they make even less sense now that we
     have 10,000 light bulbs whose name is "serialNumber=XXXXX"
  b) while subject DNs can be empty, issuer DNs can't be empty if you want to
     verify the certificate.
     Finding the public key of the issuer to verify the certificate is
     annoying and often non-trivial.  There are PKIX extensions to deal
     with this, but they aren't mandatory.

These are essentially issues with how the certificate semantics are encoded
into the ASN.1, not really a problem with the DER itself.  The lack of good
DER encoders/decoders (I've never seen a pull parser, I'm sure Heimdal
includes one, but I've never seen it) is the PITA.

I couldn't figure out what the conclusion of your slides were, btw.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-