Re: [Cfrg] Outline -> was Re: normative references

Paul Lambert <> Thu, 16 January 2014 21:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 064BF1ACCEF for <>; Thu, 16 Jan 2014 13:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id flzKSad5aQhV for <>; Thu, 16 Jan 2014 13:55:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D77C1AC4AB for <>; Thu, 16 Jan 2014 13:55:25 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s0GLtA4C017249; Thu, 16 Jan 2014 13:55:10 -0800
Received: from ([]) by with ESMTP id 1hcwywusa4-2 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jan 2014 13:55:10 -0800
Received: from ([]) by ([]) with mapi; Thu, 16 Jan 2014 13:55:09 -0800
From: Paul Lambert <>
To: Watson Ladd <>
Date: Thu, 16 Jan 2014 13:55:08 -0800
Thread-Topic: [Cfrg] Outline -> was Re: normative references
Thread-Index: Ac8TAEa9fASxbToiQIuwRGK+lc5I7QAAuTzg
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-16_07:2014-01-16, 2014-01-16, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401160147
Cc: Yaron Sheffer <>, David McGrew <>, "" <>
Subject: Re: [Cfrg] Outline -> was Re: normative references
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jan 2014 21:55:26 -0000

⨳|The key exchange and PKIX we have now works with this restriction just
 ⨳|fine. [ ⨳] 

PKIX does not work well ... and it will not be used for my applications.
When was the last time you used a PKI based key to encrypt something?

I'm building consumer equipment that needs a simple enrollment and trust model.  We will have public keys embedded in a wide range of devices (large and small).  The enrollment process may include the presentation of a public key in machine readable form (e.g. QR code). Smaller is better.  PKI and any naming hierarchy is an unnecessary burden.  Human validation of visual information is a fall-back for the device introduction process.

Initial setup is Static and/or ephemeral DH based, signatures later required. 

[ ⨳] >The naive solution I mentioned above doesn't require any extra
 ⨳|rounds, just some more data. Yes, it is sort of a pain in highly
 ⨳|restricted environments, but I'm having trouble thinking of a highly
 ⨳|restricted environment with lots of public key ops taking place that
 ⨳|need those semantics.
[ ⨳] 
It's not the size restriction or speed that is an issue. I'm looking at making the 'trust chain' simpler.  It is not a critical mechanism ... but it would make the overall presentation of chains of related keys easier.  

Signature authenticated DH is an extra couple of steps but is viable. Key 'trust statements' just require an extra level of abstraction.

Will be proceeding with a multi key model ... unless I can find a well vetted single key algorithm suite.  That's why I'm asking here....   


 ⨳|It's never going to amount to a high percentage of the load anyway.
 ⨳|> Thanks,
 ⨳|> Paul
 ⨳|"Those who would give up Essential Liberty to purchase a little
 ⨳|Temporary Safety deserve neither  Liberty nor Safety."
 ⨳|-- Benjamin Franklin