Re: [pkix] OID encoding help

Robert Moskowitz <rgm-sec@htt-consult.com> Sun, 07 May 2023 17:20 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 9AA8CC14CE4F for <pkix@ietfa.amsl.com>; Sun, 7 May 2023 10:20:08 -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 WuKgv9qJ1b6H for <pkix@ietfa.amsl.com>; Sun, 7 May 2023 10:20:06 -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 19538C14CE2E for <pkix@ietf.org>; Sun, 7 May 2023 10:20:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 36B6B6250B; Sun, 7 May 2023 13:19:41 -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 K2SxHoOkW5Fn; Sun, 7 May 2023 13:19:34 -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 D701160944; Sun, 7 May 2023 13:19:33 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------bVuQ09FKjsRiBsC69iXfmhRW"
Message-ID: <c1561a8b-3d62-ca73-c12f-627e713c3a4c@htt-consult.com>
Date: Sun, 07 May 2023 13:19:52 -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
From: Robert Moskowitz <rgm-sec@htt-consult.com>
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> <aa247ec8-8bf3-5f14-aac0-7af21b3665c4@htt-consult.com>
In-Reply-To: <aa247ec8-8bf3-5f14-aac0-7af21b3665c4@htt-consult.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/IrAomqIKZ2aqUu9JfJhF1mMuEYc>
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 17:20:08 -0000

Or since 1.3.6.1.4.1.6715.2.6.6 is defined to have a bit-string value of 
126 bytes, there is no need for anything but that 126-byte Endorsement.

On 5/7/23 12:24, Robert Moskowitz wrote:
> 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 mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix