Re: Embedded certificate image

Anders Rundgren <anders.rundgren@telia.com> Tue, 21 July 2009 07:13 UTC

Return-Path: <owner-ietf-pkix@mail.imc.org>
X-Original-To: ietfarch-pkix-archive@core3.amsl.com
Delivered-To: ietfarch-pkix-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3946C28C25E for <ietfarch-pkix-archive@core3.amsl.com>; Tue, 21 Jul 2009 00:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level:
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu6q9zfEDB0I for <ietfarch-pkix-archive@core3.amsl.com>; Tue, 21 Jul 2009 00:13:05 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 11B4128C25D for <pkix-archive@ietf.org>; Tue, 21 Jul 2009 00:13:04 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6L6XiHi003328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 23:33:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6L6Xi8I003327; Mon, 20 Jul 2009 23:33:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail.primekey.se (walter.primekey.se [195.149.137.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6L6XVKZ003283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Mon, 20 Jul 2009 23:33:43 -0700 (MST) (envelope-from anders.rundgren@telia.com)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 0A83BC3DE1; Tue, 21 Jul 2009 08:33:30 +0200 (CEST)
Message-ID: <4A656139.3060408@telia.com>
Date: Tue, 21 Jul 2009 08:33:29 +0200
From: Anders Rundgren <anders.rundgren@telia.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
CC: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Embedded certificate image
References: <C68A7AD0.3600%stefan@aaa-sec.com>
In-Reply-To: <C68A7AD0.3600%stefan@aaa-sec.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

In the "competing" proposal, certificate images are locally stored
but not embedded in certificates.  This is a viable solution when
images are only to be consumed by the end-user.  For external
consumption (which I consider an entirely different use-case),
the existing I-D seems quite sufficient.

Anders

Stefan Santesson wrote:
> This is the first of two unresolved issues listed in the Certimage draft.
>
> Is there any reason to provide any means to embed certificate images 
> in a certificate.
>
> The reason why this might be a valid option is because we often use 
> certificates in environments that have sufficient bandwidth and memory 
> capacity to allow certificate images to be stored in the certificate 
> itself. By storing the image in the certificate, we could save a 
> network retrieval.
>
> The main counter argument is that it would be a serious disadvantage 
> if a certificate occasionally needs to be used in a constrained 
> environment and the fact that the base standard that we are updating 
> (RFC 3709) simply does not allow embedded images.
>
> One way to do this could be to store images in a separate extension 
> and then define  a way to reference that image from the logotype 
> extension through an internal reference.
>
> My proposed resolution is to exclude local storage from the current draft.
> Defining local embedding is adding unnecessary complexity to the draft.
>
> If a strong reason emerges to allow local storage, then this can be 
> defined in a separate draft.
>
> /Stefan