Re: [pkix] OID encoding help
Robert Moskowitz <rgm-sec@htt-consult.com> Sun, 07 May 2023 16:24 UTC
Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E19C151522 for <pkix@ietfa.amsl.com>; Sun, 7 May 2023 09:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie5sPJ0ASbpb for <pkix@ietfa.amsl.com>; Sun, 7 May 2023 09:24:44 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 5E31DC14CE52 for <pkix@ietf.org>; Sun, 7 May 2023 09:24:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id ED9726250B; Sun, 7 May 2023 12:24:19 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iuPc8OdT3n-W; Sun, 7 May 2023 12:24:11 -0400 (EDT)
Received: from [192.168.160.29] (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9344C60944; Sun, 7 May 2023 12:24:09 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------2jDJHMhuFngTbn0WxlCUkAbI"
Message-ID: <aa247ec8-8bf3-5f14-aac0-7af21b3665c4@htt-consult.com>
Date: Sun, 07 May 2023 12:24:29 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Russ Housley <housley@vigilsec.com>
Cc: IETF PKIX <pkix@ietf.org>
References: <37ea5bd2-ac9e-4190-0936-5c04b1bffb9c@htt-consult.com> <678D438C-D3A3-4002-9C12-D10C79272117@vigilsec.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
In-Reply-To: <678D438C-D3A3-4002-9C12-D10C79272117@vigilsec.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/tVhsZJUkFW5sVhjIkt2o9K_R4U4>
Subject: Re: [pkix] OID encoding help
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 May 2023 16:24:46 -0000
Russ, That gets me half way there. The whole point of the OID is to encode the DRIP Broadcast Endorsement (draft-ietf-drip-registries-09, sec B.3) CERT RR 254 is for encoding "certificates" per a private OID, in this case, 1.3.6.1.4.1.6715.2.6.6 An example of a 126-byte DRIP Broadcast Endorsement is: 64508ac066306cc02001003ffe3ff8058eb731967e48293470a73efd272fb7de1fffd73a33c2ae5e12f1a0bb8da5baef394da2d9d5e8ed832001003ffe00000589bbba7c404b16bb7834240bb19829151f5a673f46c600cea5a89ee4833e82a30ccb7db9a55161759a6ac29bc5fd9393a2cc4e378d2f483fcea687ad52012b410e89ca2c86f0630e So how do I put it all together? And wrt to using CERT RR, it is a bit of a hack, as there is really nothing else existing now that we can stick this in. Jim Reid feels we should just create a specific RR, and Jim knows this stuff much better than I. But for this initial testing setup CERT RR is what we are using. Bob On 5/7/23 11:18, Russ Housley wrote: > I'm nor sure how CERT RR is solving your problem, but that is not your > question. > > Since you are using pyasn1... > > >>> from pyasn1.type import univ > >>> from pyasn1.codec.der.decoder import decode as der_decoder > >>> from pyasn1.codec.der.encoder import encode as der_encoder > >>> import binascii > >>> oid = univ.ObjectIdentifier('1.3.6.1.4.1.6715.2.6.6') > >>> s = der_encoder(oid) > >>> print(binascii.hexlify(s)) > 060a2b06010401b43b020606 > >>> > > Russ > > >> On May 7, 2023, at 9:02 AM, Robert Moskowitz >> <rgm-sec@htt-consult.com> wrote: >> >> I am asking here, as this seems like a place I can at least get >> directions on where to ask for help. >> >> Challenge: write simple python code to create an OID object. >> >> Background: >> >> In draft-ietf-drip-registries, there is a 126-byte RATS-styled >> Endorsement object call the DRIP Broadcast Endorsement (sec B.3). >> This object is intended to be available publically via DNS. For >> testing and perhaps onwards all we are finding is to use the CERT RR >> and encode this as a private OID object. For initial work we will >> use oid = "1.3.6.1.4.1.6715.2.6.6", with the Endorsement as type >> BIT-STRING. >> >> So.... >> >> But I cannot google up any advise on how to do this. Given how fixed >> this is, it might even be possible to hand-figure this out and just >> make the object without involking some python asn1 library. But I am >> just stuck. >> >> So can anyone pitch in, or at least point me to some advise postings. >> >> Oh, I am doing this in F38 which has the python3-pyasn1 libary. >> >> thanks >> >> Oh course an 'easier' way would be to extent the TLSA RR to support >> this type of 'certificate'. We are already using the TLSA RR for the >> SPKI we get when we make DETs (rfc 9374). That is easy, as we get >> the DER with the keypair generation. But then this would be a change >> to TLSA and changes like that to existing RR rarely go well. >> >> Bob >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >
- [pkix] OID encoding help Robert Moskowitz
- Re: [pkix] OID encoding help Peter Gutmann
- Re: [pkix] OID encoding help Robert Moskowitz
- Re: [pkix] OID encoding help Russ Housley
- Re: [pkix] OID encoding help Robert Moskowitz
- Re: [pkix] OID encoding help Robert Moskowitz
- Re: [pkix] OID encoding help Russ Housley
- Re: [pkix] OID encoding help Robert Moskowitz
- Re: [pkix] OID encoding help Peter Gutmann
- Re: [pkix] OID encoding help Robert Moskowitz