Re: iPAddress name constraints encoding

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 <[email protected]> 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:
>  
>    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
> _______________________________________________
> 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