Re: [CGA-EXT] Comment draft-ietf-csi-hash-threat-08.txt

Ana Kukec <> Sat, 06 March 2010 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CEDD3A8FFB for <>; Sat, 6 Mar 2010 10:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o0IgiMeTq96u for <>; Sat, 6 Mar 2010 10:29:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 661D33A900B for <>; Sat, 6 Mar 2010 10:29:01 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 19:29:04 +0100
Received: from anchie-MacBook.lan ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 19:29:02 +0100
Message-ID: <>
Date: Sat, 06 Mar 2010 19:29:00 +0100
From: Ana Kukec <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
To: Roque Gagliano <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Mar 2010 18:29:03.0026 (UTC) FILETIME=[E599F920:01CABD5A]
Subject: Re: [CGA-EXT] Comment draft-ietf-csi-hash-threat-08.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Mar 2010 18:29:03 -0000

Roque Gagliano wrote:
>  Moreover, the cert. profile document particularly requests that names 
> should be "meaningless" in RPKI. This is to avoid any sort of legal 
> issues.

Just checked again RPKI cert profile (architecture) draft. There is 
definitely no MUST on not using human readable fields. It's simply that 
RPKI certs are authorization and not authentication certificates, so the 
recommendation is not be descriptive when it comes to identities, but 
rather choose effective names that will make the linkage with the 
existing database records easier.

When analyzing possible attacks, we must consider that there might be 
meaningful identities. Actually, from the attacker's point of view, even 
the identity that easies the linkage with the database might be for some 
reason meaningful and possibly predictable. After all, as long as it is 
not completely random, there is a chance that the attack will take less 
effort then the brute force attack.

Additionally, we can put the identity fields on the side. There are 
other human readable fields -- for example, validity periods.

> All in all, I believe we should not take for granted that the 
> distinguished name field for either the subject or the issuer of a 
> SEND certificate should always be human readable.

There is no assumption in the draft that any of identity fields is 
always human readable.