[Anima] resolving overload of pinnned-domain-cert field (was: Re: PKCS7 certificate SignerData certificates)

"Max Pritikin (pritikin)" <pritikin@cisco.com> Tue, 19 September 2017 14:31 UTC

Return-Path: <pritikin@cisco.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D2DCB13432B for <anima@ietfa.amsl.com>; Tue, 19 Sep 2017 07:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QR1XPpnhIVXQ for <anima@ietfa.amsl.com>; Tue, 19 Sep 2017 07:31:24 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432311330B3 for <anima@ietf.org>; Tue, 19 Sep 2017 07:31:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15248; q=dns/txt; s=iport; t=1505831484; x=1507041084; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vvuPBwPKDPvliOU0SNJMSMidEwwAVSowHBm+C8wQ6gw=; b=e5vZTCoVEgKcjgOyT+UmYLRaaRDdtaHVDlx/I40OQCcEtZUzZIgPrJk6 SRcvUcNyCohxrHkqdLJiTg9vHrnt/JhpY4eSr/mQM69afoWftxg8tmocR kK2IuKc9K1ZycywmjeKLb14vr8jtSGzxi/dUH4Krr8sTGeFzAprVAcMp3 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQCXKcFZ/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26aF4F0liSCEgoYDYFcgzoCGoRAQBcBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQIBAQEhBA06CwULAgEGGgICHwcCAgIlCxUQAgQOBYorCBCNMJ1mg?= =?us-ascii?q?W06iyMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEOgh2CAoMzK4J9hGKDKS+CMQW?= =?us-ascii?q?KGIcbj1kCh1qDXIkeghOQZ4oBiwkCERkBgTgBIQMzgQ13FUkSAYU7gU52AQEDh?= =?us-ascii?q?ikrgQWBDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="297339740"
Received: from rcdn-core-10.cisco.com ([]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 14:31:22 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com []) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8JEVMlb003761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 14:31:22 GMT
Received: from xch-aln-013.cisco.com ( by XCH-ALN-015.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 09:31:19 -0500
Received: from xch-aln-013.cisco.com ([]) by XCH-ALN-013.cisco.com ([]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 09:31:19 -0500
From: "Max Pritikin (pritikin)" <pritikin@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: Kent Watsen <kwatsen@juniper.net>, Anima WG <anima@ietf.org>
Thread-Topic: resolving overload of pinnned-domain-cert field (was: Re: [Anima] PKCS7 certificate SignerData certificates)
Thread-Index: AQHTMVP1odJBnoX0A0exraoi/Z6i0Q==
Date: Tue, 19 Sep 2017 14:31:19 +0000
Message-ID: <6DF7C15A-45A8-42BD-BF77-B0FA0524780F@cisco.com>
References: <4705.1504656568@obiwan.sandelman.ca> <ED69E4AB-9AE0-48D6-9F2F-725C71AB93DE@cisco.com> <27261.1504797560@obiwan.sandelman.ca> <E949087C-FFF3-421F-A361-097E5F5019B4@cisco.com>
In-Reply-To: <E949087C-FFF3-421F-A361-097E5F5019B4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <4BC63A539122AF4E953D6735122C7219@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wRlKOYPqPF5rsWqHIMegHvOu9Ds>
Subject: [Anima] resolving overload of pinnned-domain-cert field (was: Re: 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: Tue, 19 Sep 2017 14:31:28 -0000

There were two issues,

a) The pinned-domain-cert was used as the MASA statement for the domain root certificate in vouchers but overloaded as the Registrar certificate in voucher requests. This caused confusion and the latest text now adds a “proximity-registrar-cert” to
the voucher request. 

b) Each of these fields is a single certificate while PKI discussions often include chains. We decided that continuing with the single certificate approach is valid and are not transitioning to greater PKI integrations. No change.

The pull request fixing these two was merged with this commit:

c) There was a cut/paste error in the language around pkcs7 signatures (regarding who signs them) that was fixed with this commit:

- max

> On Sep 8, 2017, at 3:24 PM, Max Pritikin (pritikin) <pritikin@cisco.com> wrote:
> I’ve commented inline about these discussion. 
> I’ve also prepared a set of diffs to help bring clarity as per the discussion. The diffs are in this branch:
> 	https://github.com/anima-wg/anima-bootstrap/commit/bec6d97207aa8faaa600d60622c9b4650ee04934
>> On Sep 7, 2017, at 9:19 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> Max Pritikin (pritikin) <pritikin@cisco.com> wrote:
>>> The voucher-request has this additional requirement:
>>> s3.3 of BRSKI-07,
>>> The request is a "YANG-defined JSON
>>> document that has been signed using a PKCS#7 structure" as
>>> described in [I-D.ietf-anima-voucher] using the JSON encoded
>>> described in [RFC7951].  The Registrar MUST sign the request.  The
>>> entire Registrar certificate chain, up to and including the Domain
>>> CA, MUST be included in the PKCS#7 structure.
>> I feel dumb, because I was sure that I looked for such a sentence, and I
>> didn't find it.  Good that it is there.
>>>> In a signed voucher request from the pledge to the registrar the
>>>> pinned-domain-cert is that of the *PLEDGE* (signed with it's IDevID).
>>> Actually this pinned-domain-cert is thus, from s3.2 of BRSKI-07,
>>> pinned-domain-cert:  In a Pledge voucher request this is the
>>> Registrar certificate as extracted from the TLS handshake (for
>>> example the first certificate in the TLS 'certificate_list'
>>> sequence (see [RFC5246]).  This MUST be populated in a Pledge's
>>> voucher request if the "proximity" assertion is populated.
>> Huh, this is actually surprising...
>> I guess we need the Registrar to keep the same thing there, and really the
>> voucher *HAS* to be issued for this key in order for the Pledge to get out of
>> provisional state…
> The registrar “keeps” this field by populating the prior-signed-voucher-request (also preserving the Pledges signature over the proximity assertion).  
>>> I was wondering earlier today if this was confusing. We could add a
>>> leaf for “tls-domain-cert” or something. An additional point is that
>>> the *assumption* is that this is the same cert as the id-kp-cmcRA cert
>>> in the chain discussed above and in s3.3 but maybe that is an
>>> assumption too far and we should support bags of certs and arbitrary
>>> complexity? I’m tired of this PKI mess.
>> Yes, that's an assumption.
>> The *VOUCHER* that results has to match the certificate in the TLS.
>> So it makes sense for the PLEDGE to indicate what certificate it is
>> expecting.
>> That lets the Registrar be built using a variety of certificates for
>> load balancing purposes, and deals with a race condition that could occur if
>> the Registrar's certificate is renewed during the imprinting process.
>> If a Registrar wants/needs to update it's cmcRA cert, it could present
>> the previously signed voucher to the MASA with previous…
> There are two places where consistent use of Registrar cert on both legs is referenced.  
> First BRSKI-08 s4.3 indicates the MASA "MAY verify” the pledge’s proximity assertion is “consistent with the [Registrar’s Registrar's 'TLS client certificate]”. The Registrar’s TLS client certificate chain root certificate is then used to populate the ‘pinned-domain-cert’ (final paragraph s4.3).
> Second BRSKI-08 s4.4 indicates how the Pledge completes the provisional TLS authentication: "The 'pinned-domain-cert' element of the voucher contains the domain CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust anchor to immediately complete authentication of the provisional TLS connection."
> The normative language here allows for Pledges that don’t make the proximity assertion. This also allows a Registrar to present a cert to the Pledge that is *different* than the cert it presents to the MASA; so long as they are issued by the same CA and so long as the MASA allows for the discrepancy. We *could* strengthen this normative statement like so:
> 	“If the Pledge provides a proximity assertion then the MASA MUST verify…”
> The current logic is softer to allow for more flexibility in Pledge behavior. See my next comment:
>>>> a) is that certificate also included in the PKCS7 bag of certificates?
>>>> I think the answer SHOULD be yes.
>>>> b) is there any operationally valid reason why there should be additional
>>>> certificates in the PKCS7 bag?
>>>> I can not come up with one. The registrar is never going to validate
>>>> any chain that the manufacturer might have used internally to set up
>>>> their CA for their IDevID.  It cares about the end-certificate only.
>>> The reason s3.3. mandates the entire chain, including the domain CA
>>> certificate, is to allow the above consistency checks. But originally
>>> this was so that the domainCA certificate would be used for the pinned
>>> cert. Moving to just the RA cert in the pinned-domain-cert field would
>>> be a simplification? The text of the voucher-05 leaf description seems
>>> to allow this.
>> I would like it to be just the RA cert.
> Where “just the RA cert” is a simplification, true. I think the current language of using the pinned-domain-cert provides a set of benefits:
> 	a) allows the RAs to change certs as needed between voucher requests and deployments
> 	b) simplifies log verification as its always root CA certs in the log
> 	c) Ensures Pledges “pin” a root cert instead of a subcert within the tree
> 	d) For Pledges that don’t do EST they have a CA cert rather than just an RA
> 		(note: s4.7 indicates only that Pledges “SHOULD” continue with EST)
> Point (d) is important. If we change to a ‘registrar-cert’ we’d need to strengthen that recommendation to a “MUST”.
>>>> In a signed voucher request from the JRC (registrar) to the MASA the
>>>> pinned-domain-cert is that of the *Registrar* (signed with it's cmcRA marked
>>>> certificate from the domain owner's CA).
>>>> a) is that certificate also included in the PKCS7 bag of certificates?
>>>> I think the answer SHOULD be yes.
>>> This is the current language and *not* that the pinned-domain-cert is
>>> populated at all. In fact if you look at the new voucher-request-yang
>>> branch and Example (2) of the voucher requests you see:
>> Are you saying that pinned-domain-cert should not be populated in the
>> voucher request ("VR") from Registrar->MASA?
> Its populated via the prior-signed-voucher-request (see above).
>>> I think we’re close to agreeing. Some comments:
>>> I like the jwt approach to certs where they include an entire “x5c”
>>> chain rather than a single cert. Maybe we should be copying that? In
>>> particular I like it better than trying to specify extra stuff in the
>>> certificate bag. The less we depend on the pkcs#7 structure the better
>>> and I’m willing to change the above uses to meet that goal.
>> So, our pinned-domain-cert in the VR would include the entire chain?
>> What format would we use?  Is it just concatenated DER of certificates?
> Current language is *only* the Registrar’s cert. 
> 1) The Pledge attests to the seen “proximity-registrar-cert” by extracting the Registrar’s TLS server cert from the TLS handshake. This is a single cert not a chain. This new voucher request leaf name is now clearer in this point.
> 2) The MASA attests to the seen “pinned-domain-cert” by extracting the Registrar’s *root CA certificate* from the PKCS#7 signature.
> The changes in the above branch don’t effect the normative behavior but do provide clarity; I suggest we adopt them. Beyond that the question at hand is:
> Q1) should we make “registrar-cert” or “domain-cert” consistent around “registrar” or “domain” or maintain the current differences?
> Q2) if we move to “chain” should we move all the way to “domain-chain”? [1]
> My thinking is to accept my branch’s diffs but not move toward chains. 
> - max
> [1] What would ‘chain’ look like?
> x5c is well defined as a JSON field. I’d use the structure as is. Something like the language of https://tools.ietf.org/html/rfc7515#section-4.1.6 modified to this:
> 	The "proximity-domain-chain” parameter contains the X.509 public key 
> 	certificate or certificate chain [RFC5280] corresponding to the key 
> 	used for TLS server authentication by the Registrar the Pledge is communicating with.
> I have NOT made this modification.
>>>> In my code I'm doing:
>>>> i.  extract the first certificate from the PKCS7 bag, and use it to
>>>> verify the PKCS7, telling the verifyer not to validate the chain,
>>>> and not to use any certificates from the PKCS7.
>>>> I found that I could not find a way to access the content of the PKCS7
>>>> content without verifying first.  I don't know if this is a ruby-openssl,
>>>> or underlying libssl limitation yet.
>>> This is an important point. In openssl I believe I was able to crack
>>> into the details without verifying and then go back and verify once I’d
>>> extracted the cert bags.
>> I believe it should be possible, but that I may not have access to the right
>> API from ruby-openssl.  I've now upstreamed one patch for ruby-openssl, so
>> I'll probably fix that and upstream and another patch.
>>>> Alternatively, in step (i), I should try all the certificates until one
>>>> works, guarding aginst there being more than one.
>>> Dunno the options. I brought my code up this evening to relook at the
>>> pinned-cert discussion in this exact area but didn’t make any
>>> progress. I’ll try and look at it tomorrow.
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima