Re: [pkix] OID encoding help

[Robert Moskowitz <[e-mail]>]

Thanks!

And I don't think we need a new RR, but we will see as we progress.

Length here is not so important as entities looking up the Endorsements 
via DNS should have good connectivity.    In our constrained links, they 
are sent in the payloads.  This is why I designed them so consisely.  
Even at 126 bytes I am getting "ouch" comments.

On 5/7/23 14:23, Russ Housley wrote:
> Bob:
>
> RFC 4398 says:
>
>    The OID private type indicates a private format certificate specified
>    by an ISO OID prefix.  The certificate section will start with a
>    one-octet unsigned OID length and then a BER-encoded OID indicating
>    the nature of the remainder of the certificate section.  This can be
>    an X.509 certificate format or some other format.  X.509 certificates
>    that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
>    type, not the OID private type.  Recognition of private certificate
>    types need not be based on OID equality but can use various forms of
>    pattern matching such as OID prefix.
>
> Your encoded OID is 12 bytes, so the field begins with 0x0c.  Next is 
> the OID (0x060a2b06010401b43b020606).  Next is the 126-byte DRIP 
> Broadcast Endorsement.
>
> I'll observe tat you can save 13 bytes by registering a new  CERT RR: 
> certificate type [1] for the DRIP Broadcast Endorsement, I don't know 
> if that matters here.
>
> Russ
>
> [1] https://www.iana.org/assignments/cert-rr-types/cert-rr-types.xhtml
>
>
>> On May 7, 2023, at 1:19 PM, Robert Moskowitz 
>> <[e-mail]> wrote:
>>
>> 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 
>>>>> <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>
>>>
>>>
>>> _______________________________________________
>>> pkix mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>