Re: [Technical Errata Reported] RFC5280 (5876)

Russ Housley <[email protected]>
Newsgroups gmane.ietf.x509
Message-ID <[email protected]>
I am unaware of this causing any trouble with implementation, so I think this should be set to "held for document update".

Russ


> On Oct 16, 2019, at 4:45 AM, RFC Errata System <[email protected]> wrote:
> 
> The following errata report has been submitted for RFC5280,
> "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5876
> 
> --------------------------------------
> Type: Technical
> Reported by: David Woodhouse <[email protected]>
> 
> Section: 4.2.1.6
> 
> Original Text
> -------------
> 
>   When the subjectAltName extension contains an iPAddress, the address
>   MUST be stored in the octet string in "network byte order", as
>   specified in [RFC791]. 
> 
> Corrected Text
> --------------
> 
>   When the subjectAltName extension contains an IP address, the address
>   MUST be stored in the iPAddress (an octet string). The address 
>   MUST be stored in the octet string in "network byte order", as
>   specified in [RFC791]. 
> 
> Notes
> -----
> For email addresses and domain names, this section is very prescriptive:
> 
>   When the subjectAltName extension contains an Internet mail address,
>   the address MUST be stored in the rfc822Name. 
> ...
>   When the subjectAltName extension contains a domain name system
>   label, the domain name MUST be stored in the dNSName…
> 
> However, for IP addresses, it's possible to interpret the current wording as saying that *if* you happen to choose the iPAddress form for an IP address, then you must represent that as big-endian. I suspect this was a poor choice of wording and the intent was to say that you MUST use the iPAddress form for an IP address.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5280 (draft-ietf-pkix-rfc3280bis-11)
> --------------------------------------
> Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
> Publication Date    : May 2008
> Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.