Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New requirement: certlint testing

1,023 views
Skip to first unread message

Kathleen Wilson

unread,
Feb 8, 2016, 3:18:49 PM2/8/16
to mozilla-dev-s...@lists.mozilla.org
All,

We recently added two tests that CAs must perform and resolve errors for
when they are requesting to enable the Websites trust bit for their root
certificate.

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for
the root certificate. Then click on the 'Search' button. Then click on
the 'Run cablint' link. All errors must be resolved/fixed.

Test 2) Browse to https://cert-checker.allizom.org/ and enter the test
website and click on the 'Browse' button to provide the PEM file for the
root certificate. Then click on 'run certlint'. All errors must be
resolved/fixed.

I added these to item #15 of
https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate

This has sparked some discussions in Bugzilla Bugs that I think we
should move here to mozilla.dev.security.policy so that everyone may
benefit from the resulting decisions.

So, if you have feedback or questions about these new tests, please add
them here.

Thanks,
Kathleen

Kathleen Wilson

unread,
Feb 8, 2016, 3:22:44 PM2/8/16
to mozilla-dev-s...@lists.mozilla.org
Also, to clarify...

Already-included root certificates are grandfathered in, but all new
root certificates need to meet the BRs and pass these certlint tests
without error before they can be included. However, we are open to
updating the certlint tests, as long as the updates are in line with the
BRs.

Kathleen


Kathleen Wilson

unread,
Feb 8, 2016, 3:43:19 PM2/8/16
to mozilla-dev-s...@lists.mozilla.org
One topic currently under discussion in Bug #1201423 is regarding root
certificates with serial number of 0. The error being returned by
http://cert-checker.allizom.org/ is "Serial number must be positive".

Arguments raised in the bug:

>>> RFC 5280 is not ambiguous as to whether zero is positive or not.
>>> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
>>> Note: Non-conforming CAs may issue certificates with serial numbers
>>> that are negative or zero. Certificate users SHOULD be prepared to
>>> gracefully handle such certificates.
>>> So zero is clearly non-conforming.

>> The whole RFC5280 section 4.1 refers to the information associated
with the
>> subject of the certificate and the CA that issued it. This is not a
>> certificate issued by a CA, it is a self-signed certificate, which
is the
>> trust-anchor itself.


> We believe that this section applies to issued certificates.
> Quoting the beginning of the section:
> The sequence TBSCertificate contains information associated with the
> subject of the certificate and the CA that issued it.
>
> Thus, it only applies to certificates issued by a CA, and not to the CA
> itself.


Does section 4.1 of RFC5280 apply to root certificates?

Is a root certificate with serial number 00 compliant with RFC5280 and
the BRs?

As always, I will appreciate your thoughtful and constructive
contributions to this discussion.

Kathleen








Peter Bowen

unread,
Feb 8, 2016, 4:07:52 PM2/8/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Feb 8, 2016 at 12:18 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> We recently added two tests that CAs must perform and resolve errors for
> when they are requesting to enable the Websites trust bit for their root
> certificate.
>
> Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the
> root certificate. Then click on the 'Search' button. Then click on the 'Run
> cablint' link. All errors must be resolved/fixed.

Kathleen,

As I understand it, the currently policy for most CT logs (which is
where crt.sh gets data) is that the root must already be in a root
program (Apple, Google Android/Chrome OS, Microsoft, or Mozilla) or
cross-signed by a root in those programs to be included in the log.
Therefore I think it is reasonable to expect that new roots are not
included in crt.sh. I'm assuming the second test checks the uploaded
root certificate, so that should be sufficient for testing.

Thanks,
Peter

Kathleen Wilson

unread,
Feb 8, 2016, 4:12:34 PM2/8/16
to mozilla-dev-s...@lists.mozilla.org
On 2/8/16 1:07 PM, Peter Bowen wrote:
> On Mon, Feb 8, 2016 at 12:18 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>> We recently added two tests that CAs must perform and resolve errors for
>> when they are requesting to enable the Websites trust bit for their root
>> certificate.
>>
>> Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the
>> root certificate. Then click on the 'Search' button. Then click on the 'Run
>> cablint' link. All errors must be resolved/fixed.
>
> Kathleen,
>
> As I understand it, the currently policy for most CT logs (which is
> where crt.sh gets data) is that the root must already be in a root
> program (Apple, Google Android/Chrome OS, Microsoft, or Mozilla) or
> cross-signed by a root in those programs to be included in the log.


Correct. In such cases no cert is found, but also no errors returned.


> Therefore I think it is reasonable to expect that new roots are not
> included in crt.sh.


Some are in crt.sh -- especially for those CAs who are new to Mozilla's
program.


> I'm assuming the second test checks the uploaded
> root certificate, so that should be sufficient for testing.

I could be wrong, but I think there is value in both tests, especially
for those CAs who are in other root programs, and not yet in Mozilla's
root program.

Kathleen


Kurt Roeckx

unread,
Feb 8, 2016, 4:32:37 PM2/8/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Feb 08, 2016 at 12:42:46PM -0800, Kathleen Wilson wrote:
>
> One topic currently under discussion in Bug #1201423 is regarding root
> certificates with serial number of 0. The error being returned by
> http://cert-checker.allizom.org/ is "Serial number must be positive".

I think a root CA is a certificate like any other, it just happens
to sign itself. So I think it should follow the rules for every
other certificate it signs, including that the serial must be
unique and positive, and non-sequential and contain at least 20
bit of entropy.


Kurt

Kurt Roeckx

unread,
Feb 8, 2016, 4:37:00 PM2/8/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Feb 08, 2016 at 12:18:12PM -0800, Kathleen Wilson wrote:
> All,
>
> We recently added two tests that CAs must perform and resolve errors for
> when they are requesting to enable the Websites trust bit for their root
> certificate.
>
> Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the
> root certificate. Then click on the 'Search' button. Then click on the 'Run
> cablint' link. All errors must be resolved/fixed.
>
> Test 2) Browse to https://cert-checker.allizom.org/ and enter the test
> website and click on the 'Browse' button to provide the PEM file for the
> root certificate. Then click on 'run certlint'. All errors must be
> resolved/fixed.
>
> I added these to item #15 of
> https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate
>
> This has sparked some discussions in Bugzilla Bugs that I think we should
> move here to mozilla.dev.security.policy so that everyone may benefit from
> the resulting decisions.

So you're requesting this for new CAs? What about existing CAs?
Should we file bugs in bugzilla about the issues it found? Are
they supposed to look at it themself and fix things?


Kurt

Kathleen Wilson

unread,
Feb 8, 2016, 5:30:40 PM2/8/16
to mozilla-dev-s...@lists.mozilla.org
Not much you can do about a currently-included root certificate other
than re-issue the root certificate which can cause many other problems.

We will let the currently-included root certificates remain as-is
(assuming proper CP/CPS/audits...), but all new root certificates must
pass the tests before they may be included.

Thanks,
Kathleen

Kurt Roeckx

unread,
Feb 8, 2016, 5:36:55 PM2/8/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Feb 08, 2016 at 02:30:05PM -0800, Kathleen Wilson wrote:
>
> Not much you can do about a currently-included root certificate other than
> re-issue the root certificate which can cause many other problems.

So I was under the impression that they needed to check their
currently signed certificates. Should they only check their own
root CA certicate for lint errors?


Kurt

Kathleen Wilson

unread,
Feb 8, 2016, 5:46:07 PM2/8/16
to mozilla-dev-s...@lists.mozilla.org
Yes, CAs should check the certificates chaining up to their included
root certs.

Bugzilla Bugs may be filed for non-BR-compliant certificates chaining up
to included root certificates, and added to the dependency list for
https://bugzilla.mozilla.org/show_bug.cgi?id=1029147

Unfortunately I do not have the bandwidth to chase these down, but I can
help get the bugs directed to the responsible CA representative.

Note that I think there are still some things with the certlint tests
that need to be ironed out, before filing bugs for every reported error.

Thanks,
Kathleen

Peter Bowen

unread,
Feb 8, 2016, 5:56:10 PM2/8/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Feb 8, 2016 at 2:46 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>
> Note that I think there are still some things with the certlint tests that
> need to be ironed out, before filing bugs for every reported error.

I am unaware of anything that is flagged as Fatal or Error on non-CA
certificates that is an open issue.

The one item on CA certificates that is a questionable Error is
whether a CA must have a commonName. I don't think Mozilla requires
such, so this should not be considered an error for Mozilla purposes.

Thanks,
Peter

(author of certlint)

Kathleen Wilson

unread,
Feb 8, 2016, 6:12:45 PM2/8/16
to mozilla-dev-s...@lists.mozilla.org
FNMT is asking about one...

Test website: https://www.sede.fnmt.gob.es/certificados
Root Cert: http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt
Error
- BR certificates with organizationName must include either localityName
or stateOrProvinceName
- BR certificates may not contain DirName type alternative names

https://bugzilla.mozilla.org/show_bug.cgi?id=435736#c158
""
Also, regarding the error "BR certificates must not contain
directoryName type alternative name", it has been discussed yet at
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/7wIZmwp4qGQ.

As it was commented, our certificates are compliant with this
requirement as we set the Domain Name (there is at least a DNSName).
Also, in order to comply with all applicable law related to eGovernment
and identification of eOffices, administrative ID info must be set at
SAN extension. As stating at section 8 of BRs we are oblied to do so.

Even if you look at CABForum EV Guidelines (9.2.2), about Subject
Alternative Name it is just said:
"This extension MUST contain one or more host Domain Name(s) owned or
controlled by the Subject and to be associated with the Subject’s
server. Such server MAY be owned and operated by the Subject or another
entity (e.g., a hosting service). Wildcard certificates are not allowed
for EV Certificates.

You'll agree that this is a less restrictive assertion (and it's about
EV certificates wich are more sensitive and requirements are harder) and
it should be taken into account.

I suggest to change the error message to a warning in order to allow CAs
to explain its especial circumstances.
""

Should I file a github Issue?

(thanks for creating certlint!)

Kathleen

Peter Bowen

unread,
Feb 8, 2016, 6:45:48 PM2/8/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Feb 8, 2016 at 3:12 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 2/8/16 2:56 PM, Peter Bowen wrote:
>>
There are two different issues here. However it is important to note
for both that the certificate in question is not an EV certificate, so
the EV Guidelines do not apply.

For the first, the BRs say:

Certificate Field: subject:localityName (OID: 2.5.4.7) Required if the
subject:organizationName field is present and the
subject:stateOrProvinceName field is absent.
Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8) Required
if the subject:organizationName field is present and
subject:localityName field is absent.

So you clearly must include at least one or the other.

For the second, the Baseline Requirements are very clear: "Each entry
MUST be either a dNSName containing the Fully‐Qualified Domain Name or
an iPAddress containing the IP address of a server."

dirName is neither a dNSName nor an iPAddress. Therefore the
requirement is not met.

It may be that Mozilla wants to consider an audit qualification that
says that including Directory Names is acceptable, but it does not
meet the current Baseline Requirements.

Thanks,
Peter

Kurt Roeckx

unread,
Feb 8, 2016, 6:55:16 PM2/8/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Feb 08, 2016 at 03:12:10PM -0800, Kathleen Wilson wrote:
> Error
> - BR certificates with organizationName must include either localityName or
> stateOrProvinceName

This is one of those I check too:
https://www.roeckx.be/certificates/subject_org_no_place.png

The last few months there are about 1500 certificates per month
generated that fail this check.

But it seems there question was actually not about this error, but
the other.


Kurt

Matt Palmer

unread,
Feb 8, 2016, 9:58:15 PM2/8/16
to dev-secur...@lists.mozilla.org
On Mon, Feb 08, 2016 at 12:42:46PM -0800, Kathleen Wilson wrote:
> One topic currently under discussion in Bug #1201423 is regarding root
> certificates with serial number of 0. The error being returned by
> http://cert-checker.allizom.org/ is "Serial number must be positive".
>
> Arguments raised in the bug:
>
> >>> RFC 5280 is not ambiguous as to whether zero is positive or not.
> >>> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
> >>> Note: Non-conforming CAs may issue certificates with serial numbers
> >>> that are negative or zero. Certificate users SHOULD be prepared to
> >>> gracefully handle such certificates.
> >>> So zero is clearly non-conforming.
>
> >> The whole RFC5280 section 4.1 refers to the information associated with
> >> the subject of the certificate and the CA that issued it. This is not
> >> a certificate issued by a CA, it is a self-signed certificate, which is
> >> the trust-anchor itself.
>
> > We believe that this section applies to issued certificates.
> > Quoting the beginning of the section:
> > The sequence TBSCertificate contains information associated with the
> > subject of the certificate and the CA that issued it.
> >
> > Thus, it only applies to certificates issued by a CA, and not to the CA
> > itself.
>
> Does section 4.1 of RFC5280 apply to root certificates?

My understanding of the terminology is that a CA is not a certificate, it is
a role (or person, or organisation, or function). To put it another way,
"certificates don't issue certificates, CAs issue certificates". In this
way, it becomes fairly clear that the self-signed certificate which is
usually used as the trust anchor is a "certificate issued by a CA", as much
as any other.

- Matt

Ryan Sleevi

unread,
Feb 9, 2016, 3:57:39 AM2/9/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, February 8, 2016 at 12:43:19 PM UTC-8, Kathleen Wilson wrote:

> One topic currently under discussion in Bug #1201423 is regarding root
> certificates with serial number of 0. The error being returned by
> http://cert-checker.allizom.org/ is "Serial number must be positive".
>
> Arguments raised in the bug:
> >>> So zero is clearly non-conforming.

I agree that this is painfully and explicitly obvious to any reading of RFC 5280.

>
> >> The whole RFC5280 section 4.1 refers to the information associated
> with the
> >> subject of the certificate and the CA that issued it. This is not a
> >> certificate issued by a CA, it is a self-signed certificate, which
> is the
> >> trust-anchor itself.
<snip>
> Does section 4.1 of RFC5280 apply to root certificates?

A certificate cannot be both a certificate and not-a-certificate. The term CA is defined within RFC 5280, and consistent with both the Baseline Requirements and ITU/X.509, as the operational entity who causes issuance. That is, there is a CA, which possesses a key pair and a name, and they cause issuance of certificates.

Note that the argument that 4.1.2 does not apply, based on Section 4.1, is to ignore both context and intent of RFC 5280. The term CA refers to the organizational entity ("certification authority", Section 3 of RFC 5280), not to the specific certificate. As such, when a CA (organization) uses a Root CA Key Pair (Section 6.1.1.1 of the Baseline Requirements) to sign Certificate Data (as defined in Section 1.6.1 of the BRs), then that act is to cause issuance of a Certificate (an act explicitly mentioned in Section 6.1.1.1p3 of the BRs). As such, the issued certificate MUST conform with RFC 5280

Further, I'm surprised (and disappointed) to see a CA argue this is somehow not the case, given that Section 3.2 of RFC 5280 makes it clear that self-issued and self-signed certificates are two distinct subclasses of the notion of CA certificate, and that certificate is a term and structure itself defined within RFC 5280. The discussion of trust anchors is a non-sequitur of client behaviour defined in Section 6.1 of RFC 5280, but that does not obviate the technical profile defined within Section 4.1, and merely describes how a conforming client should make use of that information, nor does it exempt such information from conforming (as evidenced in Section 6.2 of RFC 5280).

To their unfortunate credit, they are not the only CA to make this argument - that the root CA is somehow exempt from the Baseline Requirements ( https://bugzilla.mozilla.org/show_bug.cgi?id=555156#c95 ), but I think to accept that argument would be to create a significant loophole that would put users at real risk.

> Is a root certificate with serial number 00 compliant with RFC5280 and
> the BRs?

Such a certificate is non-compliant with RFC 5280.

As such, the certificate is also not compliant with the Baseline Requirements, therefore not with the Mozilla Program Requirements.

Erwann Abalea

unread,
Feb 9, 2016, 9:55:44 AM2/9/16
to mozilla-dev-s...@lists.mozilla.org
> One topic currently under discussion in Bug #1201423 is regarding root
> certificates with serial number of 0. The error being returned by
> http://cert-checker.allizom.org/ is "Serial number must be positive".
>
> Arguments raised in the bug:
>
> >>> RFC 5280 is not ambiguous as to whether zero is positive or not.
> >>> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
> >>> Note: Non-conforming CAs may issue certificates with serial numbers
> >>> that are negative or zero. Certificate users SHOULD be prepared to
> >>> gracefully handle such certificates.
> >>> So zero is clearly non-conforming.

Objection, votre honneur!

The above excerpt from RFC5280 is only a note. The paragraph saying that a serial number must be positive is this one:

-----
The serial number MUST be a positive integer assigned by the CA to
each certificate. It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique
certificate). CAs MUST force the serialNumber to be a non-negative
integer.
-----

Please note that in the same paragraph, it is said that the serial number must be positive and that the serial number must be non-negative.
This is ambiguous regarding to 0.

For native english speakers, the number 0 is neither positive nor negative, and is therefore a member of the non-negative set of numbers, and also a member of the non-positive set of numbers.
For french native speakers, 0 is both positive and negative (it's even the only number that is at the same time positive, negative, and pure imaginary).

In my opinion, 0 is a perfectly acceptable serial number, but I'm french, whence bizarre. That said, 0 is a poor choice for a serial number, close to the cliff.
Even ignoring my frenchyness, 0 is a non-negative number, therefore is allowed by this exact paragraph.

> >> The whole RFC5280 section 4.1 refers to the information associated
> with the
> >> subject of the certificate and the CA that issued it. This is not a
> >> certificate issued by a CA, it is a self-signed certificate, which
> is the
> >> trust-anchor itself.
>
> > We believe that this section applies to issued certificates.
> > Quoting the beginning of the section:
> > The sequence TBSCertificate contains information associated with the
> > subject of the certificate and the CA that issued it.
> >
> > Thus, it only applies to certificates issued by a CA, and not to the CA
> > itself.
>
> Does section 4.1 of RFC5280 apply to root certificates?

Section 4.1 defines the structure of a certificate, so it clearly applies to root certificates.
A trust anchor doesn't need to be materialized by a certificate, but every root program does so.

> Is a root certificate with serial number 00 compliant with RFC5280 and
> the BRs?

X.509 doesn't restrict the serialNumber to anything.
RFC2459 didn't either.
RFC3250/5280, a profile of X.509, introduced restrictions on serial numbers, with an ambiguity regarding to 0.
BR doesn't clarify the 0 position.

I read the ambiguity as a yes.

Peter Bowen

unread,
Feb 9, 2016, 10:45:29 AM2/9/16
to Erwann Abalea, mozilla-dev-s...@lists.mozilla.org
On Tue, Feb 9, 2016 at 6:55 AM, Erwann Abalea <eab...@gmail.com> wrote:
> Le lundi 8 février 2016 21:43:19 UTC+1, Kathleen Wilson a écrit :
>> On 2/8/16 12:22 PM, Kathleen Wilson wrote:
>>
>> One topic currently under discussion in Bug #1201423 is regarding root
>> certificates with serial number of 0. The error being returned by
>> http://cert-checker.allizom.org/ is "Serial number must be positive".
>>
>> Arguments raised in the bug:
>>
>> >>> RFC 5280 is not ambiguous as to whether zero is positive or not.
>> >>> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
>> >>> Note: Non-conforming CAs may issue certificates with serial numbers
>> >>> that are negative or zero. Certificate users SHOULD be prepared to
>> >>> gracefully handle such certificates.
>> >>> So zero is clearly non-conforming.
>
> Objection, votre honneur!
>
> The above excerpt from RFC5280 is only a note. The paragraph saying that a serial number must be positive is this one:
>
> -----
> The serial number MUST be a positive integer assigned by the CA to
> each certificate. It MUST be unique for each certificate issued by a
> given CA (i.e., the issuer name and serial number identify a unique
> certificate). CAs MUST force the serialNumber to be a non-negative
> integer.
> -----
>
> Please note that in the same paragraph, it is said that the serial number must be positive and that the serial number must be non-negative.
> This is ambiguous regarding to 0.
>
> For native english speakers, the number 0 is neither positive nor negative, and is therefore a member of the non-negative set of numbers, and also a member of the non-positive set of numbers.
> For french native speakers, 0 is both positive and negative (it's even the only number that is at the same time positive, negative, and pure imaginary).
>
> In my opinion, 0 is a perfectly acceptable serial number, but I'm french, whence bizarre. That said, 0 is a poor choice for a serial number, close to the cliff.
> Even ignoring my frenchyness, 0 is a non-negative number, therefore is allowed by this exact paragraph.
>
>> Is a root certificate with serial number 00 compliant with RFC5280 and
>> the BRs?
>
> X.509 doesn't restrict the serialNumber to anything.
> RFC2459 didn't either.
> RFC3250/5280, a profile of X.509, introduced restrictions on serial numbers, with an ambiguity regarding to 0.
> BR doesn't clarify the 0 position.
>
> I read the ambiguity as a yes.

I think the total of the section taken together makes that authors'
intent clear:

4.1.2.2. Serial Number

The serial number MUST be a positive integer assigned by the CA to
each certificate. It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique
certificate). CAs MUST force the serialNumber to be a non-negative
integer.

Note: Non-conforming CAs may issue certificates with serial numbers
that are negative or zero. Certificate users SHOULD be prepared to
gracefully handle such certificates.


Serial numbers must be positive. Negative or zero values are non-conforming.

However, unlike with negative numbers, there is no chance that an
improper encoding of zero (i.e. too many or too few zero bytes) will
cause the value to change. Therefore, I don't see having a zero
integer as a major issue. I fully appreciate that CAs frequently
participate in multiple root programs and may want to use use the
serial number in authority key identifiers, so having to change the
serial number can be a major problem.

I would suggest that Mozilla make it clear that zero is not acceptable
for certs with a notBefore after a certain date but accept others as
grandfathered.

Thanks,
Peter

Kurt Roeckx

unread,
Feb 9, 2016, 11:58:08 AM2/9/16
to Medin, Steven, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson
On Tue, Feb 09, 2016 at 09:31:22AM -0500, Medin, Steven wrote:
> How does the diffusion of early toBeSigned entropy create value for an event
> performed once? 

I'm not sure I understand the question. The BR have this 20 bit
of entropy for all certificates. But it's a SHOULD not a MUST.
And I guess for CAs that don't sign subscriber certificate it's
not that important.


Kurt

Erwann Abalea

unread,
Feb 9, 2016, 1:42:14 PM2/9/16
to mozilla-dev-s...@lists.mozilla.org
Digging more into RFC2459 evolution.
2459bis-draft01 changed the serial number from an integer to a positive integer.
2459bis-draft03 added the "non-negative" part, the 20 octets limit, and the conflicting Note.
2459bis later drafts only changed small things (a coma, a may into a MAY, etc).

I tried to find discussions about those 2 major changes in the PKIX mailing list. Nothing. Discussing about the author's intent is then difficult.

An errata has been proposed in 2012: http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3200 with no action so far.

The ASN.1 definition of the CertificateSerialNumber stayed as an INTEGER with no value constraint; it was already possible in the ASN.1 1988 syntax (X.208) used to write the standard.

> Serial numbers must be positive. Negative or zero values are non-conforming.

I disagree, but.

> However, unlike with negative numbers, there is no chance that an
> improper encoding of zero (i.e. too many or too few zero bytes) will
> cause the value to change. Therefore, I don't see having a zero
> integer as a major issue. I fully appreciate that CAs frequently
> participate in multiple root programs and may want to use use the
> serial number in authority key identifiers, so having to change the
> serial number can be a major problem.
>
> I would suggest that Mozilla make it clear that zero is not acceptable
> for certs with a notBefore after a certain date but accept others as
> grandfathered.

That may be acceptable.

raf...@gmail.com

unread,
Feb 10, 2016, 1:20:22 PM2/10/16
to mozilla-dev-s...@lists.mozilla.org
Regarding the issue of including a directoryName in SAN, that is a requirement by Spanish laws to issue "Sede Electrónica" certs (Electronic Office of Goverment sites).

> It may be that Mozilla wants to consider an audit qualification that
> says that including Directory Names is acceptable

Maybe that could be a solution for Spanish CAs.

Mads Egil Henriksveen

unread,
Feb 11, 2016, 9:05:53 AM2/11/16
to Kurt Roeckx, Medin, Steven, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson

The entropy requirement is not that important for certificates signed by a Root CA, because a Root CA and its private key must be kept offline or air gapped and will not be exposed to the same threats as an "online CA" signing Subscriber certificates.

The main cause for the entropy requirement is to protect against (hash) collision attacks and I don't see this as an actual threat to a Root CA.

Regards
Mads
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Rob Stradling

unread,
Feb 11, 2016, 11:16:00 AM2/11/16
to Jeremy Rowley, Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
I wouldn't mind if "Test 1) Browse to https://crt.sh/" was made a
suggestion rather than a requirement.

https://cert-checker.allizom.org/ can already accept and "run certlint"
on a user-submitted certificate. Could a "run cablint" button be added too?
Also, could this tool be run from mozilla.org (just so that people who
don't read backwards will realize that it's operated by CA-neutral
Mozilla ;-) ) ?

I think the important points are:
- The CA MUST check that they are not issuing certs that violate any
of the BRs.
- Mozilla WILL check that the CA is not issuing certs that violate
any of the BRs.

If a CA doesn't get a clean bill of health when Mozilla do their checks,
then it's that CA's fault for not using the available tools. :-)

On 10/02/16 23:50, Jeremy Rowley wrote:
> I don't think we should have to use a competitor's product to evaluate this.
> Are we permitted to set up our own instance of this using the open source to
> do the testing? There should be that option considering IP rights have not
> been freely granted on all this software.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

Kathleen Wilson

unread,
Feb 11, 2016, 1:06:07 PM2/11/16
to mozilla-dev-s...@lists.mozilla.org
On 2/11/16 8:15 AM, Rob Stradling wrote:
> I wouldn't mind if "Test 1) Browse to https://crt.sh/" was made a
> suggestion rather than a requirement.
>
> https://cert-checker.allizom.org/ can already accept and "run certlint"
> on a user-submitted certificate. Could a "run cablint" button be added
> too?
> Also, could this tool be run from mozilla.org (just so that people who
> don't read backwards will realize that it's operated by CA-neutral
> Mozilla ;-) ) ?
>
> I think the important points are:
> - The CA MUST check that they are not issuing certs that violate any
> of the BRs.
> - Mozilla WILL check that the CA is not issuing certs that violate
> any of the BRs.
>
> If a CA doesn't get a clean bill of health when Mozilla do their checks,
> then it's that CA's fault for not using the available tools. :-)


That sounds reasonable to me, so I updated the wiki page...

https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate
"" 15. Test!!!
....
- The CA MUST check that they are not issuing certificates that violate
any of the CA/Browser Forum Baseline Requirements (BRs). Mozilla WILL
check that the CA is not issuing certificates that violate any of the
BRs by performing the following tests.
-- CA/Browser Forum Compliance: Browse to https://crt.sh/ and enter the
SHA-1 Fingerprint for the root certificate. Then click on the 'Search'
button. Then click on the 'Run cablint' link. All errors must be
resolved/fixed. Warnings should also be either resolved or explained.
-- Cert chain of test website: Browse to
https://cert-checker.allizom.org/ and enter the test website and click
on the 'Browse' button to provide the PEM file for the root certificate.
Then click on 'run certlint'. All errors must be resolved/fixed.
Warnings should also be either resolved or explained.
....
""

Thanks,
Kathleen


Jakob Bohm

unread,
Feb 11, 2016, 1:23:34 PM2/11/16
to mozilla-dev-s...@lists.mozilla.org
More precisely, it is not that important for certificates whose
attributes were most certainly submitted to the CA by a highly
controlled and non-malicious internal source within the CA
organization, such as the certificates of other internal CA
certificates (internal sub-CAs and the self-signed CA cert)
OCSP signers etc.

It remains an important security measure when signing anything
requested from outside, including 3rd party sub-CA certificates, cross
certificates for the roots of other CAs, certificates for more remote
parts of the CA's organization (such as certificates for the Symantec
software business issued by a Symantec owned CA) etc.

The fact that recent NSS code no longer checks the AKI, only the Issuer
DN, makes the precise value of other identifying properties in a root
cert even less important to Mozilla (but note that this bug does not
apply to all users of the Mozilla CA list).


On 11/02/2016 15:05, Mads Egil Henriksveen wrote:
>
> The entropy requirement is not that important for certificates signed by a Root CA, because a Root CA and its private key must be kept offline or air gapped and will not be exposed to the same threats as an "online CA" signing Subscriber certificates.
>
> The main cause for the entropy requirement is to protect against (hash) collision attacks and I don't see this as an actual threat to a Root CA.
>
> Regards
> Mads
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+mads.henriksveen=buypa...@lists.mozilla.org] On Behalf Of Kurt Roeckx
> Sent: 9. februar 2016 17:58
> To: Medin, Steven
> Cc: mozilla-dev-s...@lists.mozilla.org; Kathleen Wilson
> Subject: Re: New requirement: certlint testing
>
> On Tue, Feb 09, 2016 at 09:31:22AM -0500, Medin, Steven wrote:
>> How does the diffusion of early toBeSigned entropy create value for an
>> event performed once?
>
> I'm not sure I understand the question. The BR have this 20 bit of entropy for all certificates. But it's a SHOULD not a MUST.
> And I guess for CAs that don't sign subscriber certificate it's not that important.
>
>


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

raf...@gmail.com

unread,
Feb 12, 2016, 5:00:31 AM2/12/16
to mozilla-dev-s...@lists.mozilla.org

> That sounds reasonable to me, so I updated the wiki page...
>
> https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate
> "" 15. Test!!!
> ....
> - The CA MUST check that they are not issuing certificates that violate
> any of the CA/Browser Forum Baseline Requirements (BRs). Mozilla WILL
> check that the CA is not issuing certificates that violate any of the
> BRs by performing the following tests.
> -- CA/Browser Forum Compliance: Browse to https://crt.sh/ and enter the
> SHA-1 Fingerprint for the root certificate. Then click on the 'Search'
> button. Then click on the 'Run cablint' link. All errors must be
> resolved/fixed. Warnings should also be either resolved or explained.
> -- Cert chain of test website: Browse to
> https://cert-checker.allizom.org/ and enter the test website and click
> on the 'Browse' button to provide the PEM file for the root certificate.
> Then click on 'run certlint'. All errors must be resolved/fixed.
> Warnings should also be either resolved or explained.
> ....
> ""
>
> Thanks,
> Kathleen

Regarding this point, how will be addressed the issue about AdministrativeID (directoryName) in SAN of electronic offices?

As it has been said, all Spanishs CAs are issuing certs in this way in order to comply with all applicable law related to eGovernment and identification of eOffices. As stating at section 8 of BRs they are oblied to do so.

It should be an exception to support this special feature.

David Keeler

unread,
Feb 12, 2016, 1:21:14 PM2/12/16
to dev-secur...@lists.mozilla.org
On 02/11/2016 08:15 AM, Rob Stradling wrote:
> https://cert-checker.allizom.org/ can already accept and "run certlint"
> on a user-submitted certificate. Could a "run cablint" button be added
> too?

The way it's implemented, "run certlint" actually runs cablint, which as
I understand it is a superset of the checks certlint performs. I can
change the label if that would be more clear.

> Also, could this tool be run from mozilla.org (just so that people who
> don't read backwards will realize that it's operated by CA-neutral
> Mozilla ;-) ) ?

I'll see what I can do about moving the domain. The reason it's that way
right now is because we don't currently have a webdev team supporting
that site to the same level that mozilla.org sites are.

Cheers,
David

signature.asc

Jakob Bohm

unread,
Feb 14, 2016, 1:48:18 PM2/14/16
to mozilla-dev-s...@lists.mozilla.org
On 12/02/2016 12:03, Medin, Steven wrote:
> There's no requestor control of validityNotBefore for an offline CA signing
> event, and certainly none with an online CA since the Playstation attack.
> There's limited control of toBeSigned: CAs will grab the asserted subject
> DN, public key, and toss the decorations in the PKCS#10 away. They'll amend
> the DN as they see fit based on vetting and any omissions and set validity
> dates based on the moment the offline root is exposed to perform the event.
> They're bringing multiple humans together at an externally unpredictable
> time (timezone even) and day.
>
> Even though subordination can be external or beyond core PKI realm, you
> can't get chosen plaintext or birthday with an offline CA. RapidSSL was
> another story entirely and even though they were an outlier, the 20-bit
> serial entropy that resulted was certainly warranted at the end entity tier.
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mo
> zilla.org] On Behalf Of Jakob Bohm
> Sent: Thursday, February 11, 2016 1:23 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: New requirement: certlint testing
>
> It remains an important security measure when signing anything requested
> from outside, including 3rd party sub-CA certificates, cross certificates
> for the roots of other CAs, certificates for more remote parts of the CA's
> organization (such as certificates for the Symantec software business issued
> by a Symantec owned CA) etc.
>

Note that the realistic variation in the validity dates (as seen from
someone already well enough posed to submit requests in the first
place) is a lot less than the 160 bit minimum of serial number entropy.

Just because the offline CA processes poses a significant slowdown of
any attacks, it does not entirely prevent attacks that require a low
number of "rounds", where each round submits 1 or more requests and
awaits the signed certs.

Hence my suggestion that as a prudent security measure, seemingly
random serial numbers should still be generated for any requests not
from the innermost circle of the CA operations "castle". Examples that
would be excluded would be self-signing the root certificate and
signing any locally hosted major subsystems generating their keys in
local high security hardware, such as some locally hosted subCAs and
some OCSP responders. However it would not be prudent for requests
generated or transmitted through less secure systems, such as
software-only OCSP responders or systems located off site (or just
outside the doubly secured inner sanctum of the building).

In Mozilla policy terms this would imply that Mozilla typically cannot
know if such CA-related certificates are securely on-site and thus
should not enforce the 160-bit randomness rules for certificate types
where this exception might apply.

However auditors *should* (perhaps in a future CAB/F BR) be required to
specifically check that any low-entropy-serial-number certificates
generated do in fact refer to such secure on-site systems. As these
will be low in number (perhaps less than 10), and each directly name
the system they refer to, this would be a simple case of traditional
by-the-numbers auditing:

"An automated log search (similar to the crt.sh tools but run against
more complete internal logs) listed the following certificates with
low entropy serial numbers: A.B, C.D, E.F and G.H, A.B is the root
cert, OK. C.D is the HSM in the OCSP responder on shelf 3 in rack 2
in the secure cage, OK. E.F. (revoked) was the HSM in the old subCA
on shelf 5 in rack 1 in the cage, which has been decommissioned and
securely destroyed as per audited document 234, OK. G.H is the HSM
of the current off-line EV subCA on shelf 1 in rack 1 in the cage,
that issues batches of end entity certificates in a daily ceremony
and updated revocation data in more frequent ceremonies, OK. All
accounted for and in line with the requirement, next item."

(Of cause the published audit would omit the specific locations of
those servers, that would be in an longer internal document available
only to insiders).

Matt Palmer

unread,
Feb 14, 2016, 3:10:57 PM2/14/16
to dev-secur...@lists.mozilla.org
On Fri, Feb 12, 2016 at 02:00:26AM -0800, raf...@gmail.com wrote:
> Regarding this point, how will be addressed the issue about
> AdministrativeID (directoryName) in SAN of electronic offices?
>
> As it has been said, all Spanishs CAs are issuing certs in this way in
> order to comply with all applicable law related to eGovernment and
> identification of eOffices. As stating at section 8 of BRs they are
> oblied to do so.

I assume that by "section 8 of BRs", you are referring to the point which
states, "The CA SHALL at all times issue certificates and operate its PKI in
accordance with all law applicable to its business and the Certificates it
issues in every jurisdiction it which it operates"?

If so, have you complied with the next paragraph of section 8 of the BRs,
which states "The parties involved SHALL notify the CA/Browser Forum of the
facts, circumstances, and law(s) involved, so that the CA/Browser Forum may
revise the requirements accordingly."?

If you haven't, then you're acting in bad faith by attempting to selectively
apply the provisions of the BRs, rather than taking them as a whole in the
spirit which they were intended. If you *have*, then it would be valuable
to summarise the deliberations of the Forum here, so that the Mozilla
community may evaluate the outcomes of those deliberations with regards to
the relevant Mozilla policies.

> It should be an exception to support this special feature.

No, the CABF should amend the requirements to match reality, and then
everyone else can change their tools as a result.

- Matt

--
I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course -- the computer
industry didn't even foresee that the century was going to end.
-- Douglas Adams

Steve

unread,
Feb 14, 2016, 3:59:04 PM2/14/16
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
While time isn't entropic and in its minutes and seconds there are more
variable bits than the 20 required by policies, the main influences in a
subordination process are air gap, limitations on the number of rounds, and
lack of control of the plaintext.

Subordination occurs with paper contracts and security officers and
internal auditors and sneakernet. That produces both controls and low
predictability. In my experience, an outlying case would be where an
external candidate for subordination receives more than two sets of
certificates in response to requests.

In every case where practical and possible and a volume of key use events
are occurring, serial entropy has a value. But in justifying that you make
two points I'd like to explore further:

- What low-round attacks could exploit creation of a two byte sequential
serial in a case where the submitter does not control the entire
plaintext? Or the serial number itself? Or the submission process? The
Playstation attack was not just 18 hour birthdaying, it was discovery of a
pliable and predictable CA issuance process. It was watching the pace of
sequential serial number progression for weeks, nudging it even, to get
near the target number near the target date. It was flooding the system
with auto-approved requests for sequentially assigned serial numbers and
predictable validity date/time when that t-minus six seconds moment arrived.

- Why does HSM vs software keys matter? That's hypothetically, as all
subordinate keys are in HSMs. The subordinate exists already, signed by
either a root or senior subordinate. Its own serial (arcane use of AKI
aside) isn't relevant to that which it signs. Same question goes for inner
sanctum vs fielded certs.

Ultimately, yes, do the best things everywhere, no dispute whatsoever. But
among us, can we share an opinion that there comes a point on a cold winter
night when another blanket offers no value? Rationalizing two byte serials
in offline processes rather than encoding their prohibition into audit
isn't an attempt to keep us awake worrying, it's more to prevent smothering
us.

Kind regards,
Steve

On Sun, Feb 14, 2016 at 1:48 PM Jakob Bohm <jb-mo...@wisemo.com> wrote:

> On 12/02/2016 12:03, Medin, Steven wrote:
> > There's no requestor control of validityNotBefore for an offline CA
> signing
> > event, and certainly none with an online CA since the Playstation attack.
> > There's limited control of toBeSigned: CAs will grab the asserted subject
> > DN, public key, and toss the decorations in the PKCS#10 away. They'll
> amend
> > the DN as they see fit based on vetting and any omissions and set
> validity
> > dates based on the moment the offline root is exposed to perform the
> event.
> > They're bringing multiple humans together at an externally unpredictable
> > time (timezone even) and day.
> >
> > Even though subordination can be external or beyond core PKI realm, you
> > can't get chosen plaintext or birthday with an offline CA. RapidSSL was
> > another story entirely and even though they were an outlier, the 20-bit
> > serial entropy that resulted was certainly warranted at the end entity
> tier.
> >
> > -----Original Message-----
> > From: dev-security-policy
> > [mailto:dev-security-policy-bounces+steve.medin
> =verizonbu...@lists.mo
> > zilla.org] On Behalf Of Jakob Bohm
> > Sent: Thursday, February 11, 2016 1:23 PM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: New requirement: certlint testing
> >

Jakob Bohm

unread,
Feb 14, 2016, 5:08:34 PM2/14/16
to mozilla-dev-s...@lists.mozilla.org
On 14/02/2016 21:58, Steve wrote:
> While time isn't entropic and in its minutes and seconds there are more
> variable bits than the 20 required by policies, the main influences in a
> subordination process are air gap, limitations on the number of rounds, and
> lack of control of the plaintext.
>

I read it as 20 *bytes* (160 bits) corresponding to the minimum
supported serial number size in some of the standards (and the maximum
ditto in too many versions of NSS).

> Subordination occurs with paper contracts and security officers and
> internal auditors and sneakernet. That produces both controls and low
> predictability. In my experience, an outlying case would be where an
> external candidate for subordination receives more than two sets of
> certificates in response to requests.
>
This would not help against the attacks I was trying to guard against
(more below).

> In every case where practical and possible and a volume of key use events
> are occurring, serial entropy has a value. But in justifying that you make
> two points I'd like to explore further:
>
> - What low-round attacks could exploit creation of a two byte sequential
> serial in a case where the submitter does not control the entire
> plaintext? Or the serial number itself? Or the submission process? The
> Playstation attack was not just 18 hour birthdaying, it was discovery of a
> pliable and predictable CA issuance process. It was watching the pace of
> sequential serial number progression for weeks, nudging it even, to get
> near the target number near the target date. It was flooding the system
> with auto-approved requests for sequentially assigned serial numbers and
> predictable validity date/time when that t-minus six seconds moment arrived.
>

Let's assume (for purposes of argument) that within the 10+ years
lifetime of a root, a major adversary discovers an unpublished attack
which requires getting the CA to sign a message whose hash matches some
pattern, and that this can be achieved with a reasonable probability
(say 1%) by getting the CA to sign a certificate with certain
combinations of the requestable field values combined with prediction
within a small (but not zero) margin of the CA selected field.

Such an adversary could quietly observe the pattern of issued
certificates (which are public and can be observed with no active
attack or active requests), then pay/place someone in the margins of
the CA organization to place a calculated request at a time where the
signing circumstances will be fairly predictable (e.g. it will probably
be signed within a given 2 hour period, beginning 10 days after the
request). Repeat as necessary until the 1% bingo is hit.

> - Why does HSM vs software keys matter? That's hypothetically, as all
> subordinate keys are in HSMs. The subordinate exists already, signed by
> either a root or senior subordinate. Its own serial (arcane use of AKI
> aside) isn't relevant to that which it signs. Same question goes for inner
> sanctum vs fielded certs.

I was trying to emphasize that the private (and thus public) keys
submitted for signature were not generated from a lesser source, such
as a CA operated web server with software key generation, or from a too
easily compromised (i.e. large) part of the CA organization, or
transported in a way subject to interference.

This of cause because those public keys contain the largest amount of
entropy in the certificates, and the best place to introduce malicious
bits of non-entropy.

The key storage is not as important as the fact it was generated in a
provably secure and uncompromised way. A later compromise of the
signed key is much less a problem as far as attacks on the CA signature
process is concerned. Though it might be used in a much more difficult
attack on the CRL or OCSP signing process, by reporting (possibly
uncompromised) chosen certificate serial numbers for revocation.

>
> Ultimately, yes, do the best things everywhere, no dispute whatsoever. But
> among us, can we share an opinion that there comes a point on a cold winter
> night when another blanket offers no value? Rationalizing two byte serials
> in offline processes rather than encoding their prohibition into audit
> isn't an attempt to keep us awake worrying, it's more to prevent smothering
> us.

This was inspired by reports (in recent weeks, on this list, maybe even
in this thread, I don't recall right now) that some CAs had actually
assigned low (single digit even) serials to some of the initial
certificates of the types I mentioned.

Thus the exception was meant to allow current practice in cases where
it is obviously completely safe, but to reign in this to such obviously
safe cases in a way that can be routinely checked in both Mozilla
monitoring and independent official audits.

Rob Stradling

unread,
Feb 15, 2016, 5:45:58 AM2/15/16
to David Keeler, dev-secur...@lists.mozilla.org
On 12/02/16 18:21, David Keeler wrote:
> On 02/11/2016 08:15 AM, Rob Stradling wrote:
>> https://cert-checker.allizom.org/ can already accept and "run certlint"
>> on a user-submitted certificate. Could a "run cablint" button be added
>> too?
>
> The way it's implemented, "run certlint" actually runs cablint, which as
> I understand it is a superset of the checks certlint performs. I can
> change the label if that would be more clear.

Yes, please change the label. cablint's checks are indeed are a
superset of certlint's checks.

>> Also, could this tool be run from mozilla.org (just so that people who
>> don't read backwards will realize that it's operated by CA-neutral
>> Mozilla ;-) ) ?
>
> I'll see what I can do about moving the domain. The reason it's that way
> right now is because we don't currently have a webdev team supporting
> that site to the same level that mozilla.org sites are.

Thanks David.

Peter Bowen

unread,
Feb 15, 2016, 10:07:07 AM2/15/16
to Medin, Steven, mozilla-dev-s...@lists.mozilla.org, Jakob Bohm
I actually agree with Steve, but for a slightly different reason. The known attacks all required having a submitted subject key with certain properties. The CA/Browser Forum Baseline Requirements state that all CA keys (including subordinate CA keys) must be generated on HSMs during a ceremony witnessed by an independent auditor. Now it is possible that the HSM will generate an appropriate key, but it would be highly unlikely.

Further, Mozilla is requiring disclosure of all CA-certificates. I don’t know if the discussion ever closed on the timeline, but it should be quite obvious if someone is attempting to put large numbers of random bytes in a the subject Name, which is the only other attacker controlled field.

That being said, I’m not going to change cablint to remove this warning message unless the BRs are changed. Certlint and cablint intentionally follow published standards when such exist. I’ve made a number of changes since release to be more compliant and that is the path that will continue.

Thanks,
Peter

> On Feb 15, 2016, at 6:27 AM, Medin, Steven <steve...@verizon.com> wrote:
>
> If I grant the 1% probability (which I can't), that leads to maybe 10-15 attempts to get bingo. In my past practice, our guard would be raised for the third set of requests from an external party. The manual processes, even with a bribe/plant inside the CA, do work. One person cannot act alone at any part of the process. No matter how persuasive, they can't force 10:19:36 AM Friday. Granted, signing subordinate CAs does get procedural, but it doesn't get time-precise.
>
> About the 1%, we're talking about an air gapped process. Each additional request faces logistics before it clears to get near the root that are influenced by multiple people. During the attack that led to requiring serial entropy, hundreds of requests were submitted per second to cause the proper serial number to be received with the proper validity dates. The process auto-approved requests within a predictable 6 seconds. To work, it needed to converge the sequential serial number and the datetime values.
>
> I asked about the HSM relevance to the serial number of a CA or OCSP responder certificate. I agree with the reasons for hardware and that HSMs have better pRNG than sound cards.
>
> Yeah, I saw the 00 serial discussion as well. In my past, we issued sequential small serial numbers for roots and subordinates, but lately larger and random. I'm not coming at this defensively, rather to think about the true value added and whether a small serial number in a root or subordinate will mandate rebuild of a PKI in the future. If we do encode it as a rule, then any CA should know better from that point forward, and problem solved, but I'm talking about the idea that the only thing better than more is more more more.
>
> Kind regards,
> Steve
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.org] On Behalf Of Jakob Bohm
> Sent: Sunday, February 14, 2016 5:08 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: [E] Re: New requirement: certlint testing
>
> On 14/02/2016 21:58, Steve wrote:
>> While time isn't entropic and in its minutes and seconds there are
>> more variable bits than the 20 required by policies, the main
>> influences in a subordination process are air gap, limitations on the
>> number of rounds, and lack of control of the plaintext.
>>
>
> I read it as 20 *bytes* (160 bits) corresponding to the minimum supported serial number size in some of the standards (and the maximum ditto in too many versions of NSS).
>
>> Subordination occurs with paper contracts and security officers and
>> internal auditors and sneakernet. That produces both controls and low
>> predictability. In my experience, an outlying case would be where an
>> external candidate for subordination receives more than two sets of
>> certificates in response to requests.
>>
> This would not help against the attacks I was trying to guard against (more below).
>
>> In every case where practical and possible and a volume of key use
>> events are occurring, serial entropy has a value. But in justifying
>> that you make two points I'd like to explore further:
>>
>> - What low-round attacks could exploit creation of a two byte
>> sequential serial in a case where the submitter does not control the
>> entire plaintext? Or the serial number itself? Or the submission
>> process? The Playstation attack was not just 18 hour birthdaying, it
>> was discovery of a pliable and predictable CA issuance process. It
>> was watching the pace of sequential serial number progression for
>> weeks, nudging it even, to get near the target number near the target
>> date. It was flooding the system with auto-approved requests for
>> sequentially assigned serial numbers and predictable validity date/time when that t-minus six seconds moment arrived.
>>
>
> Let's assume (for purposes of argument) that within the 10+ years lifetime of a root, a major adversary discovers an unpublished attack which requires getting the CA to sign a message whose hash matches some pattern, and that this can be achieved with a reasonable probability (say 1%) by getting the CA to sign a certificate with certain combinations of the requestable field values combined with prediction within a small (but not zero) margin of the CA selected field.
>
> Such an adversary could quietly observe the pattern of issued certificates (which are public and can be observed with no active attack or active requests), then pay/place someone in the margins of the CA organization to place a calculated request at a time where the signing circumstances will be fairly predictable (e.g. it will probably be signed within a given 2 hour period, beginning 10 days after the request). Repeat as necessary until the 1% bingo is hit.
>
>> - Why does HSM vs software keys matter? That's hypothetically, as all
>> subordinate keys are in HSMs. The subordinate exists already, signed
>> by either a root or senior subordinate. Its own serial (arcane use of
>> AKI
>> aside) isn't relevant to that which it signs. Same question goes for
>> inner sanctum vs fielded certs.
>
> I was trying to emphasize that the private (and thus public) keys submitted for signature were not generated from a lesser source, such as a CA operated web server with software key generation, or from a too easily compromised (i.e. large) part of the CA organization, or transported in a way subject to interference.
>
> This of cause because those public keys contain the largest amount of entropy in the certificates, and the best place to introduce malicious bits of non-entropy.
>
> The key storage is not as important as the fact it was generated in a provably secure and uncompromised way. A later compromise of the signed key is much less a problem as far as attacks on the CA signature process is concerned. Though it might be used in a much more difficult attack on the CRL or OCSP signing process, by reporting (possibly
> uncompromised) chosen certificate serial numbers for revocation.
>
>>
>> Ultimately, yes, do the best things everywhere, no dispute whatsoever.
>> But among us, can we share an opinion that there comes a point on a
>> cold winter night when another blanket offers no value? Rationalizing
>> two byte serials in offline processes rather than encoding their
>> prohibition into audit isn't an attempt to keep us awake worrying,
>> it's more to prevent smothering us.
>
> This was inspired by reports (in recent weeks, on this list, maybe even in this thread, I don't recall right now) that some CAs had actually assigned low (single digit even) serials to some of the initial certificates of the types I mentioned.
>
> Thus the exception was meant to allow current practice in cases where it is obviously completely safe, but to reign in this to such obviously safe cases in a way that can be routinely checked in both Mozilla monitoring and independent official audits.
>
>
>>

raf...@gmail.com

unread,
Feb 15, 2016, 10:12:09 AM2/15/16
to mozilla-dev-s...@lists.mozilla.org
El domingo, 14 de febrero de 2016, 21:10:57 (UTC+1), Matt Palmer escribió:
> If so, have you complied with the next paragraph of section 8 of the BRs,
> which states "The parties involved SHALL notify the CA/Browser Forum of the
> facts, circumstances, and law(s) involved, so that the CA/Browser Forum may
> revise the requirements accordingly."?
>
> If you haven't, then you're acting in bad faith by attempting to selectively
> apply the provisions of the BRs, rather than taking them as a whole in the
> spirit which they were intended. If you *have*, then it would be valuable
> to summarise the deliberations of the Forum here, so that the Mozilla
> community may evaluate the outcomes of those deliberations with regards to
> the relevant Mozilla policies.
>

We don't agree about your insinuation of "acting in bad faith".

As far as we know, it was notified at CABForum by an Spanish CA and that approach must be accepted because all of the Spanish CAs (included those who are CAB Forum members) are issuing certificates in this way.

Maybe a Mozilla's representative at CAB Forum may supply additional information about it.


> > It should be an exception to support this special feature.
>
> No, the CABF should amend the requirements to match reality, and then
> everyone else can change their tools as a result.
>

Also, we don't suggest that tools must be modified for now but that an exception with this requirement be made, as it was suggested before: "It may be considered an audit qualification that says that including Directory Names is acceptable"

Matt Palmer

unread,
Feb 15, 2016, 2:43:35 PM2/15/16
to dev-secur...@lists.mozilla.org
On Mon, Feb 15, 2016 at 07:12:05AM -0800, raf...@gmail.com wrote:
> El domingo, 14 de febrero de 2016, 21:10:57 (UTC+1), Matt Palmer escribió:
> > If so, have you complied with the next paragraph of section 8 of the BRs,
> > which states "The parties involved SHALL notify the CA/Browser Forum of the
> > facts, circumstances, and law(s) involved, so that the CA/Browser Forum may
> > revise the requirements accordingly."?
> >
> > If you haven't, then you're acting in bad faith by attempting to selectively
> > apply the provisions of the BRs, rather than taking them as a whole in the
> > spirit which they were intended. If you *have*, then it would be valuable
> > to summarise the deliberations of the Forum here, so that the Mozilla
> > community may evaluate the outcomes of those deliberations with regards to
> > the relevant Mozilla policies.
>
> We don't agree about your insinuation of "acting in bad faith".

I didn't insinuate it. I stated it outright. If you're trying to argue
that the BRs say you have to behave in a certain way, but you're not
actually following *all* the BRs, then that's pretty much a textbook
definition of "acting in bad faith", as far as I'm concerned.

> As far as we know, it was notified at CABForum by an Spanish CA and that
> approach must be accepted because all of the Spanish CAs (included those
> who are CAB Forum members) are issuing certificates in this way.

Note that the BRs don't say, "someone" has to notify CABF. It says *you*,
as the party that is bound to act in accordance with Section 8, must notify
CABF. It doesn't say anything about you having to be a CABF member in order
to make said notification, so there's no exemption for you there.

> Maybe a Mozilla's representative at CAB Forum may supply additional
> information about it.

Or maybe you may, since you're the one arguing for the exception.

> > > It should be an exception to support this special feature.
> >
> > No, the CABF should amend the requirements to match reality, and then
> > everyone else can change their tools as a result.
>
> Also, we don't suggest that tools must be modified for now but that an
> exception with this requirement be made, as it was suggested before: "It
> may be considered an audit qualification that says that including
> Directory Names is acceptable"

It would be better if the BRs were amended, so that the qualified audit
wasn't necessary.

Out of curiosity, though, has your auditor issued such a qualification in
the past? Were you issuing certificates which warranted such a
qualification at the time your last audit was performed? If so, it would
seem we have another case of an auditor not acting in a sufficiently
rigorous manner to preserve the public trust.

- Matt

raf...@gmail.com

unread,
Feb 16, 2016, 6:05:45 AM2/16/16
to mozilla-dev-s...@lists.mozilla.org
El lunes, 15 de febrero de 2016, 20:43:35 (UTC+1), Matt Palmer escribió:

> I didn't insinuate it. I stated it outright. If you're trying to argue
> that the BRs say you have to behave in a certain way, but you're not
> actually following *all* the BRs, then that's pretty much a textbook
> definition of "acting in bad faith", as far as I'm concerned.

No comment. It's the way you see it and there is nothing more to add.

>
> > As far as we know, it was notified at CABForum by an Spanish CA and that
> > approach must be accepted because all of the Spanish CAs (included those
> > who are CAB Forum members) are issuing certificates in this way.
>
> Note that the BRs don't say, "someone" has to notify CABF. It says *you*,
> as the party that is bound to act in accordance with Section 8, must notify
> CABF. It doesn't say anything about you having to be a CABF member in order
> to make said notification, so there's no exemption for you there.

I assume that you are really referring to 9.16 (v1.3.x) :

"9.16. MISCELLANEOUS PROVISIONS
9.16.1. Entire Agreement
9.16.2. Assignment
9.16.3. Severability
If a court or government body with jurisdiction over the activities covered by these Requirements determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal. This applies only to operations or certificate issuances that are subject to the laws of that jurisdiction. The parties involved SHALL notify the CA / Browser Forum of the facts, circumstances, and law(s) involved, so that the CA/Browser Forum may revise these Requirements accordingly."

Thank you for your suggestion. We interpreted that only CAB Forum members could notify to the CAB Forum, but we are studying to do so.

> > Maybe a Mozilla's representative at CAB Forum may supply additional
> > information about it.
>
> Or maybe you may, since you're the one arguing for the exception.

You'll agree that if this subject has already been notified and discussed (we were not present), Mozilla's representative at CAB Forum would be a trusted source in order to summarise the deliberations of the Forum about this issue.


> > Also, we don't suggest that tools must be modified for now but that an
> > exception with this requirement be made, as it was suggested before: "It
> > may be considered an audit qualification that says that including
> > Directory Names is acceptable"
>
> It would be better if the BRs were amended, so that the qualified audit
> wasn't necessary.
>
Of course that if this paragraph were rewritten (e.g. as it is in EV Guidelines documents) it wouldn't be necesary any exception. For now, as it was suggested before, and audit qualification could be a solution for Spanish CAs.


Jakob Bohm

unread,
Feb 16, 2016, 10:03:16 AM2/16/16
to mozilla-dev-s...@lists.mozilla.org
A few clarifications:

On 15/02/2016 16:06, Peter Bowen wrote:
> I actually agree with Steve, but for a slightly different reason. The known attacks all required having a submitted subject key with certain properties. The CA/Browser Forum Baseline Requirements state that all CA keys (including subordinate CA keys) must be generated on HSMs during a ceremony witnessed by an independent auditor. Now it is possible that the HSM will generate an appropriate key, but it would be highly unlikely.
>

My arguments were not restricted to sub-CA certificates, but included
other root-issued certificates such as OCSP responders (for revocation
checks on root-issued certificates).

> Further, Mozilla is requiring disclosure of all CA-certificates. I don’t know if the discussion ever closed on the timeline, but it should be quite obvious if someone is attempting to put large numbers of random bytes in a the subject Name, which is the only other attacker controlled field.
>

Again, argument not restricted to sub-CA certificates.

> That being said, I’m not going to change cablint to remove this warning message unless the BRs are changed. Certlint and cablint intentionally follow published standards when such exist. I’ve made a number of changes since release to be more compliant and that is the path that will continue.
>

I agree that setting a grandfathering data for making this either an
error or a weak warning would be a simpler solution to co-existing with
the historical practice.

That grandfathering date could be based on when the published standards
introduced the requirement for different kinds of cert (there was a
discussion if the rule in one of the RFCs applied to the root cert
itself, so that one might have a different cut-off date corresponding
to when the current interpretation took effect).

Jakob Bohm

unread,
Feb 16, 2016, 10:13:23 AM2/16/16
to mozilla-dev-s...@lists.mozilla.org
On 15/02/2016 15:27, Medin, Steven wrote:
> If I grant the 1% probability (which I can't), that leads to maybe 10-15 attempts to get bingo. In my past practice, our guard would be raised for the third set of requests from an external party. The manual processes, even with a bribe/plant inside the CA, do work. One person cannot act alone at any part of the process. No matter how persuasive, they can't force 10:19:36 AM Friday. Granted, signing subordinate CAs does get procedural, but it doesn't get time-precise.
>
> About the 1%, we're talking about an air gapped process. Each additional request faces logistics before it clears to get near the root that are influenced by multiple people. During the attack that led to requiring serial entropy, hundreds of requests were submitted per second to cause the proper serial number to be received with the proper validity dates. The process auto-approved requests within a predictable 6 seconds. To work, it needed to converge the sequential serial number and the datetime values.
>

Note that the hypothetical future threat would be successful with 1%
chance after the unpredictability of the CA chosen date/serial was
taken care of. In other words 1% of the likely serial/date values
would yield an exploitable signature, even though there are probably
more than 100 such value pairs.

> I asked about the HSM relevance to the serial number of a CA or OCSP responder certificate. I agree with the reasons for hardware and that HSMs have better pRNG than sound cards.
>

It not so much the quality of the randomness (which is presumably top
notch), but the incorruptability of the generation process. In other
words the difficulty/impossibility of substituting/patching a key
generator which yields attack-friendly values.

> Yeah, I saw the 00 serial discussion as well. In my past, we issued sequential small serial numbers for roots and subordinates, but lately larger and random. I'm not coming at this defensively, rather to think about the true value added and whether a small serial number in a root or subordinate will mandate rebuild of a PKI in the future. If we do encode it as a rule, then any CA should know better from that point forward, and problem solved, but I'm talking about the idea that the only thing better than more is more more more.
>
> Kind regards,
> Steve
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.org] On Behalf Of Jakob Bohm
> Sent: Sunday, February 14, 2016 5:08 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: [E] Re: New requirement: certlint testing
>
> On 14/02/2016 21:58, Steve wrote:
>> While time isn't entropic and in its minutes and seconds there are
>> more variable bits than the 20 required by policies, the main
>> influences in a subordination process are air gap, limitations on the
>> number of rounds, and lack of control of the plaintext.
>>
>
> I read it as 20 *bytes* (160 bits) corresponding to the minimum supported serial number size in some of the standards (and the maximum ditto in too many versions of NSS).
>
>> Subordination occurs with paper contracts and security officers and
>> internal auditors and sneakernet. That produces both controls and low
>> predictability. In my experience, an outlying case would be where an
>> external candidate for subordination receives more than two sets of
>> certificates in response to requests.
>>
> This would not help against the attacks I was trying to guard against (more below).
>
>> In every case where practical and possible and a volume of key use
>> events are occurring, serial entropy has a value. But in justifying
>> that you make two points I'd like to explore further:
>>
>> - What low-round attacks could exploit creation of a two byte
>> sequential serial in a case where the submitter does not control the
>> entire plaintext? Or the serial number itself? Or the submission
>> process? The Playstation attack was not just 18 hour birthdaying, it
>> was discovery of a pliable and predictable CA issuance process. It
>> was watching the pace of sequential serial number progression for
>> weeks, nudging it even, to get near the target number near the target
>> date. It was flooding the system with auto-approved requests for
>> sequentially assigned serial numbers and predictable validity date/time when that t-minus six seconds moment arrived.
>>
>
> Let's assume (for purposes of argument) that within the 10+ years lifetime of a root, a major adversary discovers an unpublished attack which requires getting the CA to sign a message whose hash matches some pattern, and that this can be achieved with a reasonable probability (say 1%) by getting the CA to sign a certificate with certain combinations of the requestable field values combined with prediction within a small (but not zero) margin of the CA selected field.
>
> Such an adversary could quietly observe the pattern of issued certificates (which are public and can be observed with no active attack or active requests), then pay/place someone in the margins of the CA organization to place a calculated request at a time where the signing circumstances will be fairly predictable (e.g. it will probably be signed within a given 2 hour period, beginning 10 days after the request). Repeat as necessary until the 1% bingo is hit.
>
>> - Why does HSM vs software keys matter? That's hypothetically, as all
>> subordinate keys are in HSMs. The subordinate exists already, signed
>> by either a root or senior subordinate. Its own serial (arcane use of
>> AKI
>> aside) isn't relevant to that which it signs. Same question goes for
>> inner sanctum vs fielded certs.
>
> I was trying to emphasize that the private (and thus public) keys submitted for signature were not generated from a lesser source, such as a CA operated web server with software key generation, or from a too easily compromised (i.e. large) part of the CA organization, or transported in a way subject to interference.
>
> This of cause because those public keys contain the largest amount of entropy in the certificates, and the best place to introduce malicious bits of non-entropy.
>
> The key storage is not as important as the fact it was generated in a provably secure and uncompromised way. A later compromise of the signed key is much less a problem as far as attacks on the CA signature process is concerned. Though it might be used in a much more difficult attack on the CRL or OCSP signing process, by reporting (possibly
> uncompromised) chosen certificate serial numbers for revocation.
>
>>
>> Ultimately, yes, do the best things everywhere, no dispute whatsoever.
>> But among us, can we share an opinion that there comes a point on a
>> cold winter night when another blanket offers no value? Rationalizing
>> two byte serials in offline processes rather than encoding their
>> prohibition into audit isn't an attempt to keep us awake worrying,
>> it's more to prevent smothering us.
>
> This was inspired by reports (in recent weeks, on this list, maybe even in this thread, I don't recall right now) that some CAs had actually assigned low (single digit even) serials to some of the initial certificates of the types I mentioned.
>
> Thus the exception was meant to allow current practice in cases where it is obviously completely safe, but to reign in this to such obviously safe cases in a way that can be routinely checked in both Mozilla monitoring and independent official audits.
>
>
>>

Steve

unread,
Feb 16, 2016, 11:16:38 AM2/16/16
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
As long as TLS handshake performance concerns keep RFC 6961 from de facto (
https://bugzilla.mozilla.org/show_bug.cgi?id=611836) we'll need to operate
root tier responders with HSM-driven origins, cached responses, and
multiple CDNs.

Further, you're talking about a certificate that is issued by the root
owner on their own behalf. To me, that is within logical inner sanctum,
regardless of how it needs to physically extend itself beyond the
perimeter. By that point, the serial number that the root put into the
responder certificate doesn't matter - the root owner controlled the
responder key and PKCS#10 brought to their root.

In my practice, all root private key exposures face the same procedural
pre-audit, test root issuance, results review, production issuance (and
associated m of n methods), post-audit, and delivery whether a subordinate
CA or a responder certificate.

Kind regards,
Steve Medin

On Tue, Feb 16, 2016 at 10:03 AM Jakob Bohm <jb-mo...@wisemo.com> wrote:

> A few clarifications:
>
> On 15/02/2016 16:06, Peter Bowen wrote:
> > I actually agree with Steve, but for a slightly different reason. The
> known attacks all required having a submitted subject key with certain
> properties. The CA/Browser Forum Baseline Requirements state that all CA
> keys (including subordinate CA keys) must be generated on HSMs during a
> ceremony witnessed by an independent auditor. Now it is possible that the
> HSM will generate an appropriate key, but it would be highly unlikely.
> >
>
> My arguments were not restricted to sub-CA certificates, but included
> other root-issued certificates such as OCSP responders (for revocation
> checks on root-issued certificates).
>
> > Further, Mozilla is requiring disclosure of all CA-certificates. I
> don’t know if the discussion ever closed on the timeline, but it should be
> quite obvious if someone is attempting to put large numbers of random bytes
> in a the subject Name, which is the only other attacker controlled field.
> >
>
> Again, argument not restricted to sub-CA certificates.
>
> > That being said, I’m not going to change cablint to remove this warning
> message unless the BRs are changed. Certlint and cablint intentionally
> follow published standards when such exist. I’ve made a number of changes
> since release to be more compliant and that is the path that will continue.
> >
>
> I agree that setting a grandfathering data for making this either an
> error or a weak warning would be a simpler solution to co-existing with
> the historical practice.
>
> That grandfathering date could be based on when the published standards
> introduced the requirement for different kinds of cert (there was a
> discussion if the rule in one of the RFCs applied to the root cert
> itself, so that one might have a different cut-off date corresponding
> to when the current interpretation took effect).
>

Jakob Bohm

unread,
Feb 16, 2016, 12:06:52 PM2/16/16
to mozilla-dev-s...@lists.mozilla.org
In addition to the comments below, note that I conceded that simple
grandfathering based on requirement dates would probably do the job.

On 16/02/2016 17:16, Steve wrote:
> As long as TLS handshake performance concerns keep RFC 6961 from de facto (
> https://bugzilla.mozilla.org/show_bug.cgi?id=611836) we'll need to operate
> root tier responders with HSM-driven origins, cached responses, and
> multiple CDNs.

Yep, still working on RFC6961 implementation code myself.

>
> Further, you're talking about a certificate that is issued by the root
> owner on their own behalf. To me, that is within logical inner sanctum,
> regardless of how it needs to physically extend itself beyond the
> perimeter. By that point, the serial number that the root put into the
> responder certificate doesn't matter - the root owner controlled the
> responder key and PKCS#10 brought to their root.
>

I was merely arguing that the counter-arguments about specific BR and
Mozilla requirements for sub-CAs would not alleviate any hypothetical
attacks on other root-issued certs.

> In my practice, all root private key exposures face the same procedural
> pre-audit, test root issuance, results review, production issuance (and
> associated m of n methods), post-audit, and delivery whether a subordinate
> CA or a responder certificate.
>

Good for you (and all your relying parties), doesn't extend to all the
other CAs unless backed by requirements.

Gervase Markham

unread,
Feb 16, 2016, 3:06:23 PM2/16/16
to raf...@gmail.com
On 16/02/16 04:05, raf...@gmail.com wrote:
>>> Maybe a Mozilla's representative at CAB Forum may supply
>>> additional information about it.
>>
>> Or maybe you may, since you're the one arguing for the exception.
>
> You'll agree that if this subject has already been notified and
> discussed (we were not present), Mozilla's representative at CAB
> Forum would be a trusted source in order to summarise the
> deliberations of the Forum about this issue.

There has been no such notification, to my knowledge.

Gerv

raf...@gmail.com

unread,
Feb 17, 2016, 7:54:36 AM2/17/16
to mozilla-dev-s...@lists.mozilla.org
El martes, 16 de febrero de 2016, 21:06:23 (UTC+1), Gervase Markham escribió:

>
> There has been no such notification, to my knowledge.
>
> Gerv

Thanks for your feedback. Maybe it was addresed by an individual request, private or informal way...

In order to shed light on this issue, we have notified oficially this request to the CAB Forum.
0 new messages