Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)

Rob Stradling <rob.stradling@comodo.com> Mon, 31 March 2014 14:01 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C776E1A6EF2 for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 07:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.168
X-Spam-Level:
X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=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 XYPY-Vdly7pF for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 07:01:22 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1BF1A0A24 for <trans@ietf.org>; Mon, 31 Mar 2014 07:01:21 -0700 (PDT)
Received: (qmail 5964 invoked by uid 1000); 31 Mar 2014 14:01:16 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 15:01:16 +0100
Message-ID: <5339752C.7020808@comodo.com>
Date: Mon, 31 Mar 2014 15:01:16 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Peter Bowen <pzbowen@gmail.com>
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CAK6vND-NToUO3FgC-Tp-nykj-LYpDQE0AewJeF5oUHow6XSLSQ@mail.gmail.com> <53393F1F.6080005@comodo.com> <CAK6vND88x3PFM1Ay9ebwRBCabJMrjLH=c7xMtKWBJhOuwMJ-pw@mail.gmail.com>
In-Reply-To: <CAK6vND88x3PFM1Ay9ebwRBCabJMrjLH=c7xMtKWBJhOuwMJ-pw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/upPSRWQPXZB1CMZJS5LA_6-Uisk
Cc: "trans@ietf.org" <trans@ietf.org>, Rick Andrews <Rick_Andrews@symantec.com>
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 14:01:25 -0000

On 31/03/14 14:44, Peter Bowen wrote:
> On Mon, Mar 31, 2014 at 3:10 AM, Rob Stradling <rob.stradling@comodo.com> wrote:
>> On 29/03/14 03:24, Peter Bowen wrote:
>>> Instead of having "<PRIVATE>", what about replacing the redacted
>>> string with a prefixed checksum of the part?
>>>
>>> Assuming we specify CRC-32 with "+" as the prefix,
>>> "mail.corp.example.com" would become "+6f993bb2.example.com".  [...]
>>> This has the benefit of providing
>>> privacy while allowing stronger matching of the certificate.
>>
>> The aim of the PRIVATE option is to keep sub-domain names _completely
>> hidden_ from the Log, so I think that revealing any information about them
>> is problematic.
>
> If _completely_hidden_ is the requirement, then I agree that any
> option that is no f(x) = 1 (for fixed values of 1) fails.
>
> Why have the long string "(PRIVATE)" at all then?  Would a single '?'
> not be adequate?  I don't think you will ever find '?' in a real
> dNSName.

"PRIVATE" seemed a good choice of string literal from the point of view 
of explaining the idea clearly, but I'm not bothered what string literal 
we end up using.

Why does the length of the string literal concern you?

> On a related note, is there any plan to support blinding other general
> name options?  Can email addresses in rfc822Name or ipAddresses be
> blinded?

What part(s) of an IP Address could reasonably be blinded?

I think blinding part of an rfc822Name value could be useful, although 
I'm not sure it's really in scope for RFC6962-bis.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online