46 certificates issued with BR violations

[gra...@yahoo.com]

Here's the incident report:

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

Email from Wayne Thayer Oct 1, 2018

2. A timeline of the actions your CA took in response.

A. Oct 2, 2018 - Investigation began.
B. Oct 4, 2018 - Found impacted certificate policy templates.
C Oct 4, 2018 - All the certificates owners were contacted and agreed on issuance new BR compliant certificates in time convenient for them, preferably not later than by the end of this year and revocation current ones.
D. Oct 8, 2018 - Fixed impacted certificate policy templates.
E. Oct 8, 2018 - This disclosure.

Ongoing:
F. Replacement of impacted certificates
G. Training of periodic certificate policy templates validation.

3. Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.

Confirmed.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

There are 46 certificates. The certificates were issued between Feb 20, 2017 and Sep 25, 2018.

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is

logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct

problem.

Added as attachment
https://crt.sh/?caid=15985&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The the incident concerns 46 certificates in the vast majority issued on KIR S.A. internal system purposes. The root cause of this issue was human error in certificate policy templates.


Remediation items:

1. Reviewed all certificate policy templates for ensuring that all of them are BR comliant.
2. All the certificates owners were contacted and agreed on issuance new BR compliant certificates in time convenient for them, preferably not later than by the end of this year and revocation current ones.
3. Added procedural step for periodic certificate policy templates validation.


We have by the way question about error: ERROR: The 'Organization Name' field of the subject MUST be less than 64 characters.
According to https://www.ietf.org/rfc/rfc5280.txt and the note from this RFC 'ub-organization-name INTEGER ::= 64. For UTF8String or UniversalString at least four times the upper bound should be allowed. So what is the max length of this field for UTF8String?

[Nick Lamb]

On Mon, 8 Oct 2018 03:43:53 -0700 (PDT)
"piotr.grabowski--- via dev-security-policy"

<dev-secur...@lists.mozilla.org> wrote:

> We have by the way question about error: ERROR: The 'Organization
> Name' field of the subject MUST be less than 64 characters. According
> to https://www.ietf.org/rfc/rfc5280.txt and the note from this RFC
> 'ub-organization-name INTEGER ::= 64. For UTF8String or
> UniversalString at least four times the upper bound should be
> allowed. So what is the max length of this field for UTF8String?

As I understand it:

Although the word "character" is vague and should generally be avoided
in modern technical documents, in this context it seems to refer to a
Unicode code point. And "at least four times" is referring to the prior
lines of the RFC which explain that you will need more than one octet
(byte) to represent some of these characters - this is important for
resource constrained implementations.

So: Organization Names in certificates obeying RFC5280 should not
consist of more than 64 Unicode code points, when encoded in UTF-8,
those 64 code points might consume up to 256 octets (bytes)

This is NOT an excuse to write longer names which fit in 256 bytes, the
constraint is on the number of characters (Unicode code points) not the
bytes needed to encode these characters.

In practice Organization names obeying the 64 character limit from RFC
5280 are likely to fit in much fewer than 256 octets because the more
common characters such as "Ø" or "の" do not need 4 octets to encode,
whereas the 😺 Smiling Cat Emoji does need 4 octets but of course rarely
appears in the name of organizations.


Nick.

[Ryan Sleevi]

>
> On Mon, Oct 8, 2018 at 4:06 PM Nick Lamb via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On Mon, 8 Oct 2018 03:43:53 -0700 (PDT)
>> "piotr.grabowski--- via dev-security-policy"
>> <dev-secur...@lists.mozilla.org> wrote:
>>
>> > We have by the way question about error: ERROR: The 'Organization
>> > Name' field of the subject MUST be less than 64 characters. According
>> > to https://www.ietf.org/rfc/rfc5280.txt and the note from this RFC
>> > 'ub-organization-name INTEGER ::= 64. For UTF8String or
>> > UniversalString at least four times the upper bound should be
>> > allowed. So what is the max length of this field for UTF8String?
>>
>> As I understand it:
>>
>> Although the word "character" is vague and should generally be avoided
>> in modern technical documents, in this context it seems to refer to a
>> Unicode code point. And "at least four times" is referring to the prior
>> lines of the RFC which explain that you will need more than one octet
>> (byte) to represent some of these characters - this is important for
>> resource constrained implementations.
>>
>

> There is no need to speculate based on context, because the RFC uses
> precise and well-defined language.
>
> X520OrganizationName is defined precisely using ASN.1 size semantics.
>
> These semantics are specified in X.680 47.5.4, including the full
> explanation as to what the 'max length' of this field should be seen as.
> It's unambiguous.
>
> The encoding representation is then subject to the rules of X.690 8.21.10
>