IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 14 August 2019 15:38 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 6A5601200C7; Wed, 14 Aug 2019 08:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, 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 6D-5Zi81HHTD; Wed, 14 Aug 2019 08:38:49 -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 755D2120059; Wed, 14 Aug 2019 08:38:49 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 994253818C; Wed, 14 Aug 2019 11:38:00 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2E0E3A8A; Wed, 14 Aug 2019 11:38:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org
In-Reply-To: <23257.1565381837@localhost>
References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost>
X-Mailer: MH-E 8.6; nmh 1.7+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: Wed, 14 Aug 2019 11:38:48 -0400
Message-ID: <16617.1565797128@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/vpItLADnu-2Ea-uB0A9fHjia4hw>
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 15:38:52 -0000

https://tinyurl.com/y2skc9xz


Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    >> o  The subject-alt field's encoding MAY include a non-critical
    >> version of the RFC4108 defined HardwareModuleName.  (from [IDevID]
    >> section 7.2.9) If the IDevID is stored in a Trusted Platform
    >> Module (TPM), then this field MAY contain the TPM identification
    >> rather than the device's serial number.  If both fields are
    >> present, then the subject field takes precedence.

    >> "if both fields are present", but the subject field MUST be present, so
    >> this field can never take precedence.

    > I'm willing to drop, because I never got proper clarification.
    > We were told by implementors that if the IDevID is contained in a TPM that
    > the resulting IDevID often has the serialNumber of the TPM,not the device
    > itself.

    > *** MAX ***

    >> 1.  [RFC4519] section 2.31 provides an example ("WI-3005") of the
    >> Distinguished Name "serialNumber" attribute.  [RFC4514] indicates
    >> this is a printable string so no encoding is necessary.

    >> I don't understand why these references were chosen.  Why are LDAP specs
    >> authoritative about what the encoding format for the serialNumber DN
    >> attribute is?  E.g., one could look at RFC 5280 to see that
    >> X520SerialNumber is a PrintableString.

    > *** MAX ***

We have simplified the text, removed the TPM and Hardware Module Name, etc.
and clarified why we are referencing the LDAP RFC.

We have left an out that says that the Registrar may need to dig elsewhere
on a per-manufacturer basis.

    >> o  In the language of [RFC6125] this provides for a SERIALNUM-ID
    >> category of identifier that can be included in a certificate and
    >> therefore that can also be used for matching purposes.  The
    >> SERIALNUM-ID whitelist is collated according to manufacturer trust
    >> anchor since serial numbers are not globally unique.

    >> RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in
    >> the model of RFC 6125" or "provides a new SERIAL-ID category" or
    >> similar.

    > I have an open request to *** MAX *** to clarify this part.

We have resolved by this removing the reference to RFC6125.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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

v2.23.0 | Report a Bug | By Email