Re: OID encoding help

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 <[email protected]> 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 <[email protected] <mailto:[email protected]>> 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
>>>> [email protected] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> pkix mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
>

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix