[perpass] getting rid of appliance/ilom invalid certificate warnings

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 20 November 2014 18:25 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5BA1A19F2 for <perpass@ietfa.amsl.com>; Thu, 20 Nov 2014 10:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
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 tcaR2C_rAO-D for <perpass@ietfa.amsl.com>; Thu, 20 Nov 2014 10:25:33 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97751A212A for <perpass@ietf.org>; Thu, 20 Nov 2014 10:25:14 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B4A642002A; Thu, 20 Nov 2014 13:27:48 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 5FBA1637F5; Thu, 20 Nov 2014 13:25:13 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 49E0B637EA; Thu, 20 Nov 2014 13:25:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Richard Barnes <rlb@ipv.sx>
In-Reply-To: <CAL02cgQ_Szw4pFJ7nq_upEN+pCdA3tfOPi+rrydeZEZL_k5HzQ@mail.gmail.com>
References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <CAL02cgSJWVfRYoyiar74_C_tuiLVB+QkZhvq1grYLS5Qt87SMw@mail.gmail.com> <26158.1416440544@sandelman.ca> <CAL02cgQ_Szw4pFJ7nq_upEN+pCdA3tfOPi+rrydeZEZL_k5HzQ@mail.gmail.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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-sha1"; protocol="application/pgp-signature"
Date: Thu, 20 Nov 2014 13:25:13 -0500
Message-ID: <31144.1416507913@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/vWzJCluOUUe1DYSlL6SCthEhTyM
Cc: perpass <perpass@ietf.org>
Subject: [perpass] getting rid of appliance/ilom invalid certificate warnings
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Nov 2014 18:25:36 -0000

On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:
> In the case of an ILOM, we can't predict a name or an IP address which the
> device can claim... but, the manufacturer usually has a MAC address, Asset
> Tag, or other identifier which is often unique.  If only *THAT* could go
> into
> the Location Bar instead of the IP address.  Yes, this is user interface
> thing... sorta.. it's really about a different kind of URI.
>

    rlb> We do have some history of putting identifiers besides domain names
    rlb> in the URL bar.  Namely with EV certs, browsers typically display the
    rlb> authenticated owner name.

okay, but in my experience the EV cert still has to match the host part of
the zone that the user typed in.  ILOMs, home appliances, etc. get an IP
address by DHCP or SLAAC. In the IPv6 situation things are perhaps slightly
better because the odds that appliance vendors will tell peope to type in an
IPv6 address, vs using mDNS/Bonjour seem lower.
Maybe, in some of those situations, we can have a name like
       "dell-r420-ABCD1234.local" 
used, and then maybe Dell can convince someone to give them a certificate
with this name in it... but... ideally, Dell would have their own
intermediate CA, and would ship their iDRAC with a built-in certificate.

    rlb> So the real question is whether it's possible to make a PKI that can
    rlb> authenticate those identifiers.  We would of course need some new
    rlb> types for subjectAltName, but that's just more OIDs.  The more
    rlb> interesting question is how the PKI would be structured -- who are
    rlb> the trusted authorities for asset tags?

I think that CAs would have to have a new category for intermediate CAs
with subjectAltName constraints that mean they can only sign asset tags/
DeviceIDs.  Also see draft-richardson-6tisch-idevid-cert-00, which 6tisch
considers using as part of the ANIMA work.

I had no thoughts about ILOM and appliance use of this system until you
mentioned that browsers could put something different than an HTTP URL in the
Location bar.

Where could this work get done?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [