Re: Embedded certificate image

"Moudrick M. Dadashov" <md@e-net.lt> Thu, 30 July 2009 20:44 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 743DC3A684E for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 30 Jul 2009 13:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 6DyXKNbRg6jD for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 30 Jul 2009 13:44:39 -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 29C713A682F for <pkix-archive@ietf.org>; Thu, 30 Jul 2009 13:44:38 -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 n6UKLuhQ008677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 13:21:56 -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 n6UKLu2L008676; Thu, 30 Jul 2009 13:21:56 -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.ssc.lt (mail.ssc.lt [195.43.64.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UKLstn008670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Thu, 30 Jul 2009 13:21:56 -0700 (MST) (envelope-from md@e-net.lt)
Received: from lan-84-240-23-130.vln.skynet.lt ([84.240.23.130] helo=[127.0.0.1]) by mail.ssc.lt with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1MWc8H-0002he-1E; Thu, 30 Jul 2009 23:21:45 +0300
Message-ID: <4A7200D0.2020802@e-net.lt>
Date: Thu, 30 Jul 2009 23:21:36 +0300
From: "Moudrick M. Dadashov" <md@e-net.lt>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
CC: Santosh Chokhani <SChokhani@cygnacom.com>, "Timothy J. Miller" <tmiller@mitre.org>, ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Embedded certificate image
References: <C697C6A7.3A79%stefan@aaa-sec.com>
In-Reply-To: <C697C6A7.3A79%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>

Sorry, I didn't get the idea. Do you mean the CA will create those 
logotypes or the logotypes will be presented to CA as any other Subject 
related data to be included in the certificate?

M.D.

Stefan Santesson wrote:
> This is data generated by the CA.
>
> Some included elements, like logotype of the subject organization may be
> provided by the applicant but the certificate image is assembled and created
> by the CA.
>
> /Stefan
>
>
> On 09-07-30 8:55 PM, "Santosh Chokhani" <SChokhani@cygnacom.com> wrote:
>
>   
>> I do not mean to intrude, but is this data being provided by the
>> applicant or is this something structured created by the CA or gotten by
>> the CA from a source that applicant does not control.
>>
>> I ask because depending on the answer, this may become pre-image attack
>> and hence impractical.
>>
>>     
>>> -----Original Message-----
>>> From: owner-ietf-pkix@mail.imc.org
>>> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
>>> Sent: Thursday, July 30, 2009 2:32 PM
>>> To: Timothy J. Miller
>>> Cc: ietf-pkix
>>> Subject: Re: Embedded certificate image
>>>
>>>
>>> So, with all things taken into account, what is your opinion
>>> on what we should do?
>>>
>>> Do you argue that we should ignore the feature because it may
>>> enhance hash attacks?
>>>
>>> /Stefan
>>>
>>> On 09-07-30 5:32 PM, "Timothy J. Miller" <tmiller@mitre.org> wrote:
>>>
>>>       
>>>> Stefan Santesson wrote:
>>>>
>>>>         
>>>>> However, I can't escape that it feels a bit warped if we abandon
>>>>> useful features because we must design protocols to resist weak
>>>>> hashes instead of making sure that we can and do use
>>>>>           
>>> adequate hash algorithms.
>>>       
>>>> It's a risk-management decision, in the end.  The question
>>>>         
>>> is, whose 
>>>       
>>>> risk is it?  The protocol designer's, or the end user's?
>>>>
>>>>         
>>>>> On the second point, the data in both SVG and PDF/A are
>>>>>           
>>> highly structured.
>>>       
>>>>> SVG is for example an XML based vector graphic language.
>>>>>           
>>>> I can bury arbitrary amounts of unstructured data in both
>>>>         
>>> SVG and PDF/A.
>>>       
>>>>   SVG allows the same RFC2397 data URLs that you were discussing
>>>> previously, and you can embed fonts in both PDF/A (it's actually
>>>> required) and SVG.  :)
>>>>
>>>> -- Tim
>>>>
>>>>         
>>>
>>>       
>
>
>