Re: [pkix] Simple Certificate Enrollment Protocol (SCEP)

Jeffrey Walton <noloader@gmail.com> Mon, 10 November 2014 02:47 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0551A88A8 for <pkix@ietfa.amsl.com>; Sun, 9 Nov 2014 18:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 IiSE-HpU2YIp for <pkix@ietfa.amsl.com>; Sun, 9 Nov 2014 18:47:47 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B709D1A889F for <pkix@ietf.org>; Sun, 9 Nov 2014 18:47:47 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id at20so8504036iec.3 for <pkix@ietf.org>; Sun, 09 Nov 2014 18:47:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DkkUeflYdH1V14vya+eRgfLer92imR4zfqKE6O07viM=; b=kpPEjhRd26HRWsIIQzsbaoUNWvYCvjwH/e19fvH8ZR7CBspx6OqqNb7JgO9hyN5JZx qXoTPZwKDCOgoj1WJBRu+G5PlWentWd3oLa87S8fUqtQXYQKHeFec46LMIF4uQ0nCqxP rqVmp0HyWdiN1lDD75w69l+fWWDGbSoBu9c+cjqDdg4szG7USRvXLdCHLokFcFfidjxZ PJzkKr8eE2SoaT6h3D9Xg4RMFau4fJF9YWMnGXw4SCOUAPaz/Plseu9gprcNiiWka3sf z9H2J8YLm30V56ix8X6tlIP56Q4X0WyGM2633Q6o6X7JPmD+M68XKeBil+Cob8TsemLo XjAw==
MIME-Version: 1.0
X-Received: by 10.50.122.106 with SMTP id lr10mr21724215igb.32.1415587666852; Sun, 09 Nov 2014 18:47:46 -0800 (PST)
Received: by 10.107.134.194 with HTTP; Sun, 9 Nov 2014 18:47:46 -0800 (PST)
In-Reply-To: <5451138E.4000208@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB295@uxcn10-5.UoA.auckland.ac.nz> <5451138E.4000208@gmail.com>
Date: Sun, 09 Nov 2014 21:47:46 -0500
Message-ID: <CAH8yC8n0Qz0dt+_XWCPedpNhfkEZkfMEUz84LQvUfnns2c=5TA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/siP_Ytco-zGhduywDoHj6nV9E-k
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 02:47:49 -0000

On Wed, Oct 29, 2014 at 12:19 PM, Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
> The only thing that could eventually replace SCEP for "devices" including
> BYOD, would be a protocol that builds on embedded attestation keys like the
> FIDO/Google U2F scheme.  Such a scheme could completely eliminate the
> reliance on enrollment passwords.
Attestation key pairs are shared across devices by a vendor to provide
anonymity (cf.,
https://fidoalliance.org/specs/fido-u2f-overview-v1.0-rd-20141008.pdf,
page 9). I don't think one of SCEP's design goals is anonymity (but
its been a while since I looked at it and NDES).

Rather, I'm pretty sure its the opposite: during provisioning, the
SCEP admin wants to know who/what is being provisioned. In this case,
the anonymity provided by the attestation key pairs is probably
unwanted; and the uniqueness provided by a challenge password is
probably desired.

I wonder how long before the attestation key pairs start showing up in
Little Black Box (https://code.google.com/p/littleblackbox/).