IETF Logo Mail Archive

Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 04 August 2021 22:28 UTC

Return-Path: <prvs=78500edfc2=uri@ll.mit.edu>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460063A0ED1 for <spasm@ietfa.amsl.com>; Wed, 4 Aug 2021 15:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 gHiGfvUdf4-u for <spasm@ietfa.amsl.com>; Wed, 4 Aug 2021 15:28:26 -0700 (PDT)
Received: from llmx2.ll.mit.edu (llmx2.ll.mit.edu [129.55.12.48]) (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 52D863A0ECC for <spasm@ietf.org>; Wed, 4 Aug 2021 15:28:25 -0700 (PDT)
Received: from LLE2K16-HYBRD01.mitll.ad.local (LLE2K16-HYBRD01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 174MSJWs029222; Wed, 4 Aug 2021 18:28:19 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Hnjgj/ICL74dGjKKvgbxLObvMbKJMEH4lmqUA9HneMNfpYmx4EsGCU1AJHZu/FqqG9PHB4jdb2QYuXc7SUF2fL4Gi/VIMK98OsHPuZG6ln0DHw9EQ+ac5GxmWvCBt0sazGfw30pzyv+6qIqwE3NcPDWbMe177uc38yJeGrpK4Y/hCmSmVLkW94x31YTDba7lnu0ziXLUI+PeQ23kHtPaH/x8gioxfBNSawtc8tLhl88bIBXUqtarJsL5dtHkqRN6mScZHnIDM+2aUMDLmJzLKxylCrUJawrdEq+WWLxWcAgD19SmeqBXXqSoIVeCJFNNjf4Gjz41ef5VEcnyt82PBA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JPeTgw07KJiMHk9E9+eGiItGcm3wqHnusGIIMTHBD+o=; b=TYF2pG19nI9Mqmy5SLO+JC26tOLO22BvcxqGbnrSu7+sp42ovvt8KXoFAYniOZhszemsU9MICN4YgF0Hn2o9GFUkQ+mEhHdZWfS//keZDXEKXkkGB0eUVztsMvRvwowrwV/cRq3rLSTlX9exwymWfoVxX3Sg6Xs7mCLZXIXiCaWT1GbNc8w+SSZlQGcJa/4A7PDM4De8pe3jx7D8ytcxb2vxIjJuoYMlXHBaEXdHBnsCDHpcmNb+ROhHPlo0yHGa4AZaUxhb42wlObQwxN3pmKNRx6w4kviMqRiarpfpO3gtl+jin/8T944SR6DaZFMQaqOoAYtt4pjEqLAoYVj3Hg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>, LAMPS WG <spasm@ietf.org>
Thread-Topic: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)
Thread-Index: AQHXhNAH7j97rn/mLk+L5HJAqzqW96tbnMqAgADw7ICAAU3ZAIABR6MAgAA0LoCAAbQVgIAAu9UAgACTwgCAAY60gP//yZyA
Date: Wed, 04 Aug 2021 22:28:17 +0000
Message-ID: <656985A5-BED4-4BA8-9233-B3C93966016C@ll.mit.edu>
References: <87czr0ww0d.fsf@fifthhorseman.net> <FF939B28-528B-47F9-9C0C-6585D1B02FBE@vigilsec.com> <87mtq3ukk0.fsf@fifthhorseman.net> <CAErg=HHQMZ1jk+bVxA=MzVvW+9ucie7bu-N6O8Asnp0V8Rf9Bg@mail.gmail.com> <30546.1627850836@localhost> <CAErg=HHKL-E5yT0UnPKcLfMQU41iDg7GGgjsSXs3eRg8daJRkg@mail.gmail.com> <87wnp347iu.fsf@fifthhorseman.net> <1388.1627996026@localhost> <87pmuu42hf.fsf@fifthhorseman.net> <20862.1628113377@localhost>
In-Reply-To: <20862.1628113377@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=ll.mit.edu;
x-originating-ip: [129.55.200.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bb20ad29-ce30-4efa-e9a6-08d95797286e
x-ms-traffictypediagnostic: SN5P110MB0893:
x-microsoft-antispam-prvs: <SN5P110MB0893DCB5008D59A1E3E7FEAE90F19@SN5P110MB0893.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: d01j2gpqWOiyLzkURQuT6PdiXmEkUQfi8rUsMKFVNmGusEN3v4SPlyaV4X65aOaSS8fhJJRKEbLUvrqoL2cZs7gGPYbYFYzKlYpPkjlYA112CseysfhcA5Pize8OSuyjMMlMWtbJiK8ZrNzI+VV7xOE/NCgGUiNZ08HvCtc2RJKfWLOrYFgOemw4K2feYJuRp+r9m95f538aiGsR+k5HBW+7uuNq+1HlKhH6MX0QuhavYwk6wSei5wstXdkuQC7mU/E2B3j+E5hVLllN70NUQPLghXCWftMizUTa0JwlptyjrOluaxvaGk7pvIzccv89DO/+m+yt/4R6lkROdnhvVzYywm72WbOIXwaUFwITRYBBQv+/+YycgokLfXkEM1W6a+gxAV87mnCnGZKDUctxv7x3u+mtgryhEGkMX2TwGEDguFabB9EJOL+3ELL6rpm3wlvsHRlM5v4YZyM2uif6uEnpJKvwtvZFLBjMy4KfIB6HfWkdg+rdzj7/UkYqelqrXOYE3sJ4hGqPPh0ARjILjE5Gt/IvUiV3coE490TLnP/pmm9mphB0KFbt5z3b2glUawsRTdl2NZxi3oHXQesXlqJwy8niYSivjmpI3KoXgKTmMa+vqyrFip8xIfVK0/kVAB480frgxFv4nvO8NndCLBteJfom5//zu4pt74y3fn8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(5660300002)(76116006)(33656002)(316002)(6512007)(6486002)(122000001)(66446008)(66946007)(64756008)(38100700002)(2906002)(66556008)(6506007)(186003)(75432002)(83380400001)(8676002)(99936003)(66616009)(66574015)(26005)(110136005)(66476007)(2616005)(508600001)(71200400001)(38070700005)(86362001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: yR7bVfBYWR8A7N3GdL35DcTIpvd1Lwi2v3QXl7+gTmmKIewYvAi8cbv2R8rqMQW5/1rwjteJG7IlJKNeawZOTDzvYOKK2/Gdj9dpnsGEjWKVL5r1HVNLC7VgU+JyAx8H649AEDaLy49xQPtcHZaBlwtPY34OkB4i+DS3Qq8MPPv4YG0xgtbfNgnAfPCNLsubiFspqUa+pRn637R5Zu+VBfQDHZrKvfqO+/sEgNHtbNintOTgZKezEmNOwvFnFUZZevle4n9c1JrxZBdkPscJIj0cholDRG7N+B/bEidQIqSaA0Y7sCd1GPEF16gWpro93T0k5nhDZVb9+KKdpcWtxYN9AxXYdXgU/W2/CmNj9p7CUpYGGQ0ZiS09A/tNNawThOu0V6FYoFCcwqDo9ou8Mq4nAGKOKyqcFCRPlIdrRBqLjJxXTW5xz+l7yErk+SylD/svnq5oUZ77S36jgI5hCpmhFitlOAAtpEDZ2bPsj2VXdUjPD7Ryp8jQR9avjLQQylX5pu+pb5WnXBcZagB3ObgAImr2r5a8VM1W9/uCxUXc2TK7xiR7fOEazizYlBA7yoU0/yLb+ri0f7B4lLBat+yzd6jQF8lgzLgoTRFIM5GcJqa+BJ99hFgRN/r2usaJaMaYaPpbN0hrnrkFsrjq8GiZQvZmOKDQNGtKLweFsz6xYdkCeqqY22VqBe3lq1BHY0nxujUwd/yCOKls0DKhXA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3710946497_1587972165"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: bb20ad29-ce30-4efa-e9a6-08d95797286e
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2021 22:28:17.8142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0893
X-OriginatorOrg: ll.mit.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-04_07:2021-08-04, 2021-08-04 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2103310000 definitions=main-2108040138
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/bhlQYS1j0mPML8glIZs1yOb5ZVs>
Subject: Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2021 22:28:32 -0000

IMHO:

- PKCS#12 cannot "just die" because there's a ton of software that cannot import private keys, unless they're in .p12 or such.
- I concur that interoperation for private keys is nonsense.


As a side remark - generic use of indefinite-length encoding should be classified as a clinical disorder, and treated accordingly. I'd be happy to call for a DSM update.  ;-)

--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 8/4/21, 17:44, "Spasm on behalf of Michael Richardson" <spasm-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:


    Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
        > On Tue 2021-08-03 09:07:06 -0400, Michael Richardson wrote:
        >> Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
        >> > c) Adjust the creation of the PKCS#12 objects so that they have the
        >> > double OCTET STRING wrapper (one for RFC 5652 and one for RFC 7972),
        >> > without moving them into the indefinite encoding.  (maybe also warn
        >> > against PKCS#12 use here?)
        >>
        >> Does this possible changes in code in existing systems?
        >> I don't think that they will change.

        > I've been using GnuTLS to generate the objects in the draft thus far,
        > and they've been open to code changes that i've suggested in the past
        > based on input from this WG.

    okay, but my point is that it's not the flexible systems that are the
    problem, it's the inflexible systems that are keeping us from changing.

    ====

    Now, if rather than fix PKCS12, the IETF were to mark it HISTORICAL with
    clear advice on what to use.  Remembering that we have PKCS1 and PKCS8
    (RFC5208).
    RFC5915/RFC5958.
    This contributes to confusion and bits of lack of interoperation.

    (Why do we need interoperation for private keys?  Often we don't need that
    much, until someone is debugging something, or provisioning keys into an
    embedded system via JTAG...)

    I would be happy if pkcs12 just died.

    --
    Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
               Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email