Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

神明達哉 <jinmei@wide.ad.jp> Fri, 11 November 2016 17:33 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64A1295B2 for <dhcwg@ietfa.amsl.com>; Fri, 11 Nov 2016 09:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 coHsqo3aoLPl for <dhcwg@ietfa.amsl.com>; Fri, 11 Nov 2016 09:33:12 -0800 (PST)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C13A129866 for <dhcwg@ietf.org>; Fri, 11 Nov 2016 09:33:12 -0800 (PST)
Received: by mail-qt0-x22c.google.com with SMTP id w33so13503498qtc.3 for <dhcwg@ietf.org>; Fri, 11 Nov 2016 09:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8tdZ4yNs+KJE5aWbebLukR4skrMDU0BDeQiKDNb/1vM=; b=uqy9uC2s02RAPwKCE6qxmk0fIyapD2LfeOdx3fsLJq/XswYGbKrkgs7ZHoRK8rCJTa 3eu7XbA4uZ4+dWRjr0HSJYVWqlcezAYAuGtBWDs7WDq/aS+FxNv9WJZF4nUsbyHGrWZm h3nHPPc96rFnI/fN+Btqax/XS2J58/8KpcLYjFtFc9B52ZLQyNYFmWc/r1ombPNlMwQe LVBTMRmRhTjuhFRe9rKtMIva4MoI0yh1XV8m8VCoNU7zSdepFnecocsgHV97QIAKupoi DGsiMw8U9otTgYaJNcrlFYood+hnjeVMI5NGb01TkcT/7yMVPlm7Uozxso2XEGzFKja6 swVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8tdZ4yNs+KJE5aWbebLukR4skrMDU0BDeQiKDNb/1vM=; b=X+f51Rx5aecUY8G/iwvkg/KgDZ4vwvOG0aKdmCpVH5FYPvOGP3coLfogCrkJcsp7ag JQDqhQPpC0MeACYj9zSYOIb3DFmFoRj7tJAzTjyZuIjwQVylpnGXHnR8gpc8pl54Awf6 HD7adhBaDI1i0ZCllWRICyyHa51ev4WbQzziXPiMLGR38F0WCprQZBlLxV21bcLrg7a/ yer7vhIdHWDsSso1OdfTwnr/mCP06U+rtcJ1sJLN1YOUD0aISIdotQV3xz8ZPk2Q7/Yc YwKdJtRI7E2KivxIizKzKReW2hz+aaDfUZaD7Wnk4JPvuqLn/j7L6+7iwlaWiBH46aoA Laow==
X-Gm-Message-State: ABUngvcuYqyRwxagEUnq+V73YYk4/mydESBCzXDnIWE1O7Jn7WU+wOI/iCOvjLVKcFJgJH824p/1rkaJNQjeYQ==
X-Received: by 10.200.45.6 with SMTP id n6mr385475qta.220.1478885591013; Fri, 11 Nov 2016 09:33:11 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.53.155 with HTTP; Fri, 11 Nov 2016 09:33:10 -0800 (PST)
In-Reply-To: <CAJ3w4NfU9PrC9a+MGnJ=Es1yir_asHB3p1=9GfxZZ0iSe+At+Q@mail.gmail.com>
References: <CAJE_bqebwr2WUUgaNgiYS4_8L77Gxj4Os+oPRG407B6ELMEhCQ@mail.gmail.com> <CAJ3w4Ndi5Gq63n5kZnanRhLM8nWE2wsWGh0kJJLJnq=VoXLuCg@mail.gmail.com> <CAJE_bqegh1DfWjfK2BxeC_fWa0cEk-KJNP0AT-TQuEa39w_wVQ@mail.gmail.com> <CAJ3w4NdM99nv4C19Xj=aosNme+_Ymyys=xQ3UWUfeZReZC4ckA@mail.gmail.com> <CAJE_bqdhGZnK16MooiyujDgthDNnR74EiwW0OevrN6uq4b4ANw@mail.gmail.com> <CAJE_bqfKUZe2yaW1sAq7rrib0M7wz28HHtPLqCHK=vXcN6amgg@mail.gmail.com> <CAJ3w4Nd3s+ZojjiotLkKwys6truhUgK6F-90UYjcpB9iw=fKKQ@mail.gmail.com> <m2r36nuqvn.wl%jinmei.tatuya@gmail.com> <CAJ3w4NeuNYTrX4p5rtZ6UceD5ydQ-B-vY6aqQzxWnXsrDOEFEA@mail.gmail.com> <CAJE_bqdh-bgk7BHZJnaFFBr3PDj4ZnSSGeGNdQ70F7dv91iQrA@mail.gmail.com> <CAJ3w4NfU9PrC9a+MGnJ=Es1yir_asHB3p1=9GfxZZ0iSe+At+Q@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 11 Nov 2016 09:33:10 -0800
X-Google-Sender-Auth: iJiG4vn57cU93w9DRGY--sBrWCY
Message-ID: <CAJE_bqfRBYkrniWQ+vtPULTURnvyV792QNGvr8JhhZpGQ0MSdA@mail.gmail.com>
To: Lishan Li <lilishan48@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ZkAmwTbHQ4gvSXvKjm-nQPeQH68>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2016 17:33:13 -0000

At Thu, 10 Nov 2016 00:48:53 +0800,
Lishan Li <lilishan48@gmail.com> wrote:

> > It'll be possible (and probably quite common) to share the same
> > certificate (public key) for both encryption and signature.  For
> > example, if we use RSA for encryption and RSASSA, it's quite likely
> > that we can use the same public key.  But, unless we impose an
> > explicit relationship between these two algorithms as part of the
> > protocol specification we cannot always assume that, so the protocol
> > itself should be generic so that it will work even if encryption and
> > signature algorithms are totally independent.  That's why I stated the
> > above example: "add a new field for the certificate option to specify
> > for which it's supposed to be used: encryption, authentication, or
> > both."
> >
> > Whether to impose such an "explicit relationship" is a different
> > question, btw.  I think that's certainly an option and can make the
> > spec simpler at the cost of making it less flexible, but that should
> > be discussed and described in the spec explicitly, instead of leaving
> > it as an implicit assumption.
> >
> [LS]: There are two types of certificate: one type is used for encryption
> and authentication, which contains the public key for encryption algorithm;
> another type is used for signature versification, which contains the public
> key for signature algorithm. We can set one field for this. If the field is
> zero, then it indicates the first type. If the field is 1, then it
> indicates the
> second type.

There are THREE types of certificates:
- one type is used only for encryption, which contains the public key
  for the encryption algorithm
- another is used only for authentication, which contains the public
  key for the signature algorithm
- yet another is used both for encryption and authentication, which
  contains the public key for the encryption and signature algorithms.

So...

> We can set one field for this. If the field is
> zero, then it indicates the first type. If the field is 1, then it
> indicates the
> second type.

...if this is a proposal of adding a new field to the certificate
option, yes, I think that's one way forward except that there are
three types.

Alternatively, we might add both an EA-id and SA-id fields to the
option:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_CERTIFICATE       |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            EA-id              |            SA-id              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                  Certificate List(variable length)            .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(I'm not sure if this has to be a list of certificates instead of one
certificate, but that's a different question).

And we can use a value of 0 for EA-id and SA-id to mean this
certificate is not supposed to be used for encryption and signature,
respectively.  (The combination of 0, 0 makes no sense so we should
probably prohibit the use of it explicitly).

--
JINMEI, Tatuya