Thank you, yes, that is much clearer. When these values (e.g. "Alice Smith") were included in the SAN, how were they encoded? The Subject Common Name field is simply a `printableSteing`, but the Subject Alternative Names extension requires that each value within it be tagged with what kind of name it is, e.g. a `dnsName` for domain names or an `rfc822Name` for email addresses. When a name like "Alice Smith" was included in the SANs, was it encoded as an `rfc822Name`, or as something else?
Bug 1879845 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Thank you, yes, that is much clearer.
When these values (e.g. "Alice Smith") were included in the SAN, how were they encoded? The Subject Common Name field is simply a `printableSteing`, but the Subject Alternative Names extension requires that each value within it be tagged with what kind of name it is, e.g. a `dnsName` for domain names or an `rfc822Name` for email addresses. When a name like "Alice Smith" was included in the SANs, was it encoded as an `rfc822Name`, or as something else?
I will note that this explanation makes it clear that this incident is not just a case of "invalid content" in the SAN, but also a violation of the S/MIME BRs Section 7.1.4.2.1 Subject Alternative Name Extension:
> All Mailbox Addresses in the subject field... SHALL be repeated as rfc822Name... in this extension.