Re: [Gen-art] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00

Tadahiko Ito <tadahiko.ito.public@gmail.com> Thu, 20 February 2020 15:10 UTC

Return-Path: <tadahiko.ito.public@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E3512003E; Thu, 20 Feb 2020 07:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sbzidTgQeYqV; Thu, 20 Feb 2020 07:09:56 -0800 (PST)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 A9A7B120024; Thu, 20 Feb 2020 07:09:56 -0800 (PST)
Received: by mail-io1-xd2c.google.com with SMTP id k24so5036569ioc.4; Thu, 20 Feb 2020 07:09:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cVR6NzqJPwwyrZBCYpUq/ioNymyqxK/Ph1Q5o79pkCM=; b=qWflKIlWZOFE70FTaLOcNQ/my1gQHmTgSnfaVOc+FmVbzDG1lhWcnzopKUN6qE1/Cv /Ttud/rz9U5n3TgzxhS/4agXbnlhqFeYitnmzMI7BjYgZ9djGgXwV4AMCsnvhREHShpa UDxXCMl4uY4/d8vDGaqYCYna648PowatWNpzg83tMXHUpJJni+Qw6J+RPpUELXF+obhC +wwL3JYTVI/K1zAOw1yQmQs/u+NI4vyuE7hpWBaz8O7Y/heCBJOMFBpSYmITe8hA3E1/ Qi1Z5e37TAWqY5dCfSoKTsRqxWcYSqs5je9uHz9TYXok8GODF+Js/ZEovnDgrB2ZDWpZ l6qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cVR6NzqJPwwyrZBCYpUq/ioNymyqxK/Ph1Q5o79pkCM=; b=PNXBPjHl52rSb1pexrgRRii/mdF2K0qkh16BKK+MocArn4yj3kPBFKbsVem1P1VGzt 4VtPUaofjS2uPpKKVHBBJFK220RGtNlDpypKpm/1m4doHedyVi852hV6EkhCvvqFsm+g lNVwmHho1hgGaQ8pxMHy2vWfW9t+WqjLys8gj2Ghs6FQwSleTEhalsNggHlDUHp+6QSh fVXrlr/1kLihxIrgQ+STQttCabbfNOUrTZNDW9POC2wOjILhBm49VAVuOg6EGe9TM8Qv 3d7gVsOjBwaJNNzdMNT6bcLve50HzwmZNS/IJvUB1mt3pd/H7AZCQ+sNFWY4raB8JBZa N3ag==
X-Gm-Message-State: APjAAAV0/78RtUW1Vd69OekpgiEi3/cGGC+u34TcPtOWUsQdfZmT70ps tP+goPrRDyCmGq3T/imCIwvv1EbNpLoIhwH1snI=
X-Google-Smtp-Source: APXvYqwXGtnQ8EfpvEkZ4TXuf0uKLSfvPj4Kbs024wVoOapqJ8nG4xRe8xyAVayId/tAPTy71mNM5HElAX0YpN7gmqs=
X-Received: by 2002:a05:6638:1e6:: with SMTP id t6mr25778798jaq.118.1582211395598; Thu, 20 Feb 2020 07:09:55 -0800 (PST)
MIME-Version: 1.0
References: <158208167058.19287.14585229025387805615@ietfa.amsl.com> <9A18B0AA-084C-4B25-9B8B-0C166E7FA1D4@sn3rd.com>
In-Reply-To: <9A18B0AA-084C-4B25-9B8B-0C166E7FA1D4@sn3rd.com>
From: Tadahiko Ito <tadahiko.ito.public@gmail.com>
Date: Thu, 20 Feb 2020 16:09:43 +0100
Message-ID: <CAFTXyYC-c80-4tGuinexyFni7nFFypvpOA-Ega3vptKPWMKeww@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Dale Worley <worley@ariadne.com>, gen-art@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, LAMPS WG <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000031bd2c059f034c89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/sO_iNguKzpEPGSfeE9HEukGtXdI>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Feb 2020 15:10:02 -0000

Hi

let me fix a little.

>>These algorithm need a lot of metadata (including EC point, KDF
algorithm, hash algorithms, metadata of hash or KDF, etc…),
>>and we are not sure, but believe, when specified they will not use
id-ecPublicKey.
>>However, they may use SubjectPublicKeyInfo for their metadata.

we are not sure, but believe when specified they will not use
id-ecPublicKey as a algorithm,

but they may use id-ecPublicKey in the metadata field,  along with ECIES
algorithm identifier in the algorithm field.

Regards Tadahiko Ito

2020年2月20日(木) 15:49 Sean Turner <sean@sn3rd.com>:

> Dale,
>
> Hi! And, thanks for your review comments in-line.
>
> spt
>
> > On Feb 18, 2020, at 22:07, Dale Worley via Datatracker <noreply@ietf.org>
> wrote:
> >
> > Reviewer: Dale Worley
> > Review result: Ready with Issues
> >
> > I am the assigned Gen-ART reviewer for this draft.  The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed by
> > the IESG for the IETF Chair.  Please treat these comments just like
> > any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >
> > Document:  draft-ietf-lamps-5480-ku-clarifications-00
> > Reviewer:  Dale R. Worley
> > Review Date:  2020-02-18
> > IETF LC End Date:  2020-02-07
> > IESG Telechat date:  [unknown]
> >
> > Summary:
> >
> >       This draft is on the right track but has open issues, described
> >       in the review.
> >
> > The text is difficult to follow in places.  I believe that the WG has
> > a clear understanding of what is intended, but a few small editorial
> > errors have unfortunately rendered the text incorrect and
> > contradictory to RFC 5480.
>
> Sometimes when you are too familiar with the context you assume too much
> so a fresh set of eye can help!
>
> > Note that I am unfamiliar with the details of PKI certificates; this
> > review is based largely on what I have learned from RFC 5480 and this
> > I-D.
> >
> >> From the discussion it appears that id-ecDH and id-ecMQV are "key
> > agreement algorithms" and that, as such, they should not be used with
> > keyEncipherment or dataEncipherment.  [this draft, section 3]
> > Conversely, id-ecPublicKey is not a "key agreement algorithm".  [RFC
> > 5480, section 2.1.2, para. 1, sentence 1]
>
> Ah ... this might be where some of misunderstanding comes from because
> id-ecPublicKey MAY be a key agreement algorithm that is why it is
> “unrestricted”. In other words, when key agreement certificates can include
> the following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV (for EC
> MQV), or id-ecPublicKey (for any algorithm). Here’s the text from 5480
> about id-ecPublicKey being used as key agreement algrithm:
>
> If the keyUsage extension is present in an End Entity (EE)
> certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo,
> then any combination of the following values MAY be present:
>
>  digitalSignature;
>  nonRepudiation; and
>  keyAgreement.
>
> > 1.  Introduction
> >
> >   This document corrects this omission, by updating Section 3 of
> >   [RFC5480] to make it clear that neither keyEncipherment nor the
> >   dataEncipherment key usage bits are set for key agreement algorithms.
> >
> > This could be clearer by replacing or augmenting "key agreement
> > algorithms" with a description of which of these algorithms are key
> > agreement algorithms, viz., id-ecDH and id-ecMQV.  Otherwise, one must
> > first have read RFC 5480 to understand this introduction correctly.
>
> See above.
>
> I also pondered how much to put in the intro to accommodate those readers
> that are not as familiar with RFC 5480. I went the minimal route since this
> is supposed to be just adding two sentences to RFC 5480. I sure hope people
> that are not intimately familiar with RFC 5480 do immediately go read RFC
> 5480 because this draft isn’t all that much use without doing so :)
>
> > 3.  Updates to Section 3
> >
> >   If the keyUsage extension is present in a certificate that indicates
> >   id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in
> >   SubjectPublicKeyInfo, then following values MUST NOT be present:
> >
> >     keyEncipherment; and
> >     dataEncipherment.
> >
> >   If the keyUsage extension is present in a certificate that indicates
> >   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
> >   values also MUST NOT be present:
> >
> >     keyEncipherment; and
> >     dataEncipherment.
> >
> > The structure of this section is peculiar, since it presents almost
> > the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV".
> > If the intention is to say the same thing about all three, these
> > should be folded together.
>
> There are two reasons I’d like to not merge these two bits of text:
>
> 1. Agreed it is a bit odd, but it does mirror RFC 5480, which talks about
> id-ecPublicKey for CA certificates and then EE certificates and then
> id-ecDH/id-ecMQV. I guess we could collapse it, but for me then it’s a
> style thing and I’d rather mimic the RFC it’s updating.
>
> 2. With separate sentences we leave open the door for ECC encryption
> algorithms like ECIES
> <
> https://itectec.com/spec/c-3-elliptic-curve-integrated-encryption-scheme-ecies/
> >
>
> These algorithm need a lot of metadata (including EC point, KDF algorithm,
> hash algorithms, metadata of hash or KDF, etc…), and we are not sure, but
> believe, when specified they will not use id-ecPublicKey.
> However, they may use SubjectPublicKeyInfo for their metadata.
>
> If we integrate two sentence together, a possible future ECIES draft will
> conflict with our draft.
>
> > It is also not clear why the first paragraph refers to
> > AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo
> > to refer to essentially the same thing.
>
> I am pretty sure we did that to provide some context for where the OIDs
> go, but you are right the first paragraph could just of easily been:
>
>  If the keyUsage extension is present in a certificate that indicates
>  id-ecPublicKey in SubjectPublicKeyInfo,
>
> I will make that change.
>
> > But this text appears to contradict the statement in [RFC 5480] that
> > the usage of id-ecPublicKey is "unrestricted" and is not a key
> > agreement algorithm, in which case the first paragraph should say "the
> > following values MAY be present".  (In which case, the "also" in the
> > 2nd paragraph should be omitted.)
>
> See above.
>
> Cheers,
>
> spt