Re: [Anima] PKCS7 certificate SignerData certificates

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 September 2017 15:27 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A18132EAB for <anima@ietfa.amsl.com>; Thu, 7 Sep 2017 08:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Y9zL6arcTvqU for <anima@ietfa.amsl.com>; Thu, 7 Sep 2017 08:27:55 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AA1132F40 for <anima@ietf.org>; Thu, 7 Sep 2017 08:27:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DEC69203AF; Thu, 7 Sep 2017 11:31:47 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32E1E806B4; Thu, 7 Sep 2017 11:27:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Kent Watsen <kwatsen@juniper.net>
cc: "Max Pritikin (pritikin)" <pritikin@cisco.com>, Anima WG <anima@ietf.org>
In-Reply-To: <8EC759E5-598F-43B7-B63E-6008346767B6@juniper.net>
References: <4705.1504656568@obiwan.sandelman.ca> <ED69E4AB-9AE0-48D6-9F2F-725C71AB93DE@cisco.com> <8EC759E5-598F-43B7-B63E-6008346767B6@juniper.net>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 07 Sep 2017 11:27:54 -0400
Message-ID: <29158.1504798074@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/0E68_pv9cifwTnuVHE0yIUboq-s>
Subject: Re: [Anima] PKCS7 certificate SignerData certificates
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Sep 2017 15:27:56 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
    > S6 in the voucher draft says:

    > The PKCS#7 structure SHOULD also contain all the certificates leading
    > up to and including the signer's trust anchor certificate known to
    > the recipient.

Agreed.
And the MASA should know exactly what that list is for each device.

    > and S5.4 in the NETCONF zerotouch draft says:

    > The device MUST first authenticate the ownership voucher by
    > validating the signature on it to one of its preconfigured trust
    > anchors (see Section 5.1).

    > Perhaps it should add "using any addiiotional intermediate certificates
    > stapled to the voucher"?

It would be worth saying:

   "It may need to use additional intermediate certificates included
   with the signature artifact (such as PKCS7 SignerData certificates)"

    > I like a chain more than a single cert as well.  I'm ambivalent to the
    > TA cert being provided, but I'm okay with it if it alignd better with
    > x5c.

I think it's useful for intermediary auditing if the TA cert is included,
(and ignored by the pledge).  We have an existing situation with WebPKI where
some browsers complain if any TA is passed down.  During the SHA1->SHA256
switch over for intermediate CAs, it was sometimes necessary to pass
extra things that the browsers' would eventually have built-in.

    > Wah?  First, we can't assume the 1st cert is the one you want.  In ASN.1
    > parlance, it is a SET (not a SEQUENCE).  Next, my code [1] validated the
    > voucher's signature first - I don't understand the need to be
    > out-of-order
    > here.  Last, yes, you can access the contents without verification using
    > the smime -noverify flag.

I agree, I shouldn't be assuming it's the first certificate.
I'm going in via API, not CLI.

And btw, the noverify flag in the API still checks that the content is signed
by the provided certificate, it just doesn't check that the certificate is
valid.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-