Subject: [pkix] iPAddress name constraints encoding

From: Corey Bonnell <[email-masked]>
Date: Wed, 25 Aug 2021 21:06:11 +0000

Hello,

RFC 5280, section 4.2.1.10
(https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10) specifies
the following encoding for iPAddress constraints:

   The syntax of iPAddress MUST be as described in Section 4.2.1.6 with
   the following additions specifically for name constraints.  For IPv4
   addresses, the iPAddress field of GeneralName MUST contain eight (8)
   octets, encoded in the style of RFC 4632 (CIDR) to represent an
   address range [RFC4632].  For IPv6 addresses, the iPAddress field
   MUST contain 32 octets similarly encoded.  For example, a name
   constraint for "class C" subnet 192.0.2.0 is represented as the
   octets C0 00 02 00 FF FF FF 00, representing the CIDR notation
   192.0.2.0/24 (mask 255.255.255.0).
 
I believe this text makes it clear that iPAddress constraints must use CIDR
notation, but the encoding scheme specified here seems to be very
inefficient. For example, the number of bits corresponding to the network
prefix of an IPv6 constraint could alternatively be encoded in one octet as
opposed to using 16 octets to express the netmask as defined above. Does
anyone have any insight on why this (seemingly very inefficient) encoding
scheme was chosen?
 
Thanks,
Corey

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Aug 2021 17:47:49 -0400

Corey:

It was chosen because there were existing specifications that were easy to reference.  It seemed undesirable to make up a new encoding to save space in the certificate.

Russ

> On Aug 25, 2021, at 5:06 PM, Corey Bonnell <Corey.Bonnell=[email-masked]> wrote:
> 
> Hello,
> RFC 5280, section 4.2.1.10 (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10>) specifies the following encoding for iPAddress constraints:
>  
> I believe this text makes it clear that iPAddress constraints must use CIDR notation, but the encoding scheme specified here seems to be very inefficient. For example, the number of bits corresponding to the network prefix of an IPv6 constraint could alternatively be encoded in one octet as opposed to using 16 octets to express the netmask as defined above. Does anyone have any insight on why this (seemingly very inefficient) encoding scheme was chosen?
>  
> Thanks,
> Corey
> _______________________________________________
> pkix mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>