Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 14 August 2019 14:34 UTC

Return-Path: <kaduk@mit.edu>
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 86EF31208E2; Wed, 14 Aug 2019 07:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 YfzmUwRcfUnI; Wed, 14 Aug 2019 07:34:14 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2565E120043; Wed, 14 Aug 2019 07:34:13 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7EEY5eP013805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:34:07 -0400
Date: Wed, 14 Aug 2019 09:34:04 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG <iesg@ietf.org>, anima@ietf.org
Message-ID: <20190814143404.GW88236@kduck.mit.edu>
References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> <28714.1565791513@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <28714.1565791513@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/P3ShGOi8Y0FO9MOfzzlWQqt0w6Y>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 14 Aug 2019 14:34:17 -0000

On Wed, Aug 14, 2019 at 10:05:13AM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <kaduk@mit.edu> wrote:
>     >> domainID:  The domain IDentity is a unique hash based upon a
>     >> Registrar's certificate.  If the certificate includes the
>     >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
>     >> used as the domainID.  If not, then the 160-bit SHA-1 hash as
>     >> described in that section is to be used.  This value needs to be
>     >> calculated by both MASA (to populate the audit log), and by the
>     >> Registrar (to recognize itself).
>     >> 
>     >> Does this work?  We are only using SHA-1 (for identification, btw, not
>     >> for resistence to pre-image attacks) as a last resort.
> 
>     > Sorry, I'm still not seeing the justification for using SHA-1 as the
>     > fallback instead of (e.g.) SHA-256.  If the SKI is present, then
>     > definitely use that.  But if it's not present, we can define whatever
>     > we want, can't we?  It's not like "The keyIdentifier is composed of the
>     > 256-bit SHA-256 
>     > hash of the value of the BIT STRING subjectPublicKey (excluding the tag,
>     > length, and number of unused bits)" is an unreasonable amount of text ot
>     > include in the document.  Now, if there's some backwards compatibility
>     > need 
>     > or implementation challenge, we can talk about that, but all I'm seeing so
>     > far is blind adherence to an 11-year-old document for consistency's sake,
>     > and in this case I don't think consistency outweighs cryptographic
>     > modernization.
> 
> Hi, we have revised the text, making use of section 2.4 from rfc7469, which
> has a similar need.
> 
> We added a new section 5.8.2, calculation of domainID:
> 
> 5.8.2.  Calculation of domainID
> 
>    The domainID is a binary value (a BIT STRING) that uniquely
>    identifies a Registrar by the "pinned-domain-cert"
> 
>    If the "pinned-domain-cert" certificate includes the
>    SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
>    used as the domainID.  If not, then it is the SPKI Fingerprint as
>    described in [RFC7469] section 2.4 is to be used.  This value needs
>    to be calculated by both MASA (to populate the audit-log), and by the
>    Registrar (to recognize itself).
> 
>    [RFC5280] section 4.2.1.2 does not mandate that the
>    SubjectKeyIdentifier extension be present in non-CA certificates.  It
>    is RECOMMENDED that Registrar certificates (even if self-signed),
>    always include the SubjectKeyIdentifier to be used as a domainID.
> 
>    The domainID is determined from the certificate chain associated with
>    the pinned-domain-cert and is used to update the audit-log.
> 
> and referenced this section in the terminology.  This eliminates all
> references to SHA-1.  RFC7469 section 2.4 uses SHA-256.

Thank you!

> We also strengthened our statement that the SubjectKeyIdentifier SHOULD
> exist.  In the process, we recognized that we had some mismatch in
> (MY) thinking about pinned-domain-cert, thinking it was always the
> Registrar End-Entity Certificate, when in fact it is the Registrar's
> CA certificate.  As a CA certificate, it SHOULD always have the
> SubjectKeyIdentifier.

My recollection was that it was expected to be a certificate in the
Registrar's chain, probably a CA certificate but possibly an intermediate
one (i.e., not self-signed).  (And I see in 5280 "this extension MUST
appear in all conforming CA certificates".)

> We are presenting discussing whether the EE Registrar cert should get
> audited.

Okay, sounds good.

-Ben