Re: New requirement: certlint testing

[rafamdn]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Gervase Markham]

On 16/02/16 04:05, rafa...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [E] Re: New requirement: certlint testing

[Jakob Bohm]

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=verizonbusiness@lists.mozilla.org]
 On Behalf Of Jakob Bohm
Sent: Sunday, February 14, 2016 5:08 PM
To: mozilla-dev-security-pol...@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

Re: New requirement: certlint testing

[rafamdn]

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"
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [E] Re: New requirement: certlint testing

[Medin, Steven]

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=verizonbusiness@lists.mozilla.org]
 On Behalf Of Jakob Bohm
Sent: Sunday, February 14, 2016 5:08 PM
To: mozilla-dev-security-pol...@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 s

Re: New requirement: certlint testing

[Rob Stradling]

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.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Matt Palmer]

On Fri, Feb 12, 2016 at 02:00:26AM -0800, rafa...@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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Steve]

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-mozi...@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
> =verizonbusiness@lists.mo
> > zilla.org] On Behalf Of Jakob Bohm
> > Sent: Thursday, February 11, 2016 1:23 PM
> > To: mozilla-dev-security-pol...@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 lo

Re: New requirement: certlint testing

[Jakob Bohm]

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=verizonbusiness@lists.mo
zilla.org] On Behalf Of Jakob Bohm
Sent: Thursday, February 11, 2016 1:23 PM
To: mozilla-dev-security-pol...@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).





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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New requirement: certlint testing

[Medin, Steven]

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=verizonbusiness@lists.mo
zilla.org] On Behalf Of Jakob Bohm
Sent: Thursday, February 11, 2016 1:23 PM
To: mozilla-dev-security-pol...@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.


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[David Keeler]

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
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New requirement: certlint testing

[Mads Egil Henriksveen]

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=buypass...@lists.mozilla.org]
 On Behalf Of Kurt Roeckx
Sent: 9. februar 2016 17:58
To: Medin, Steven
Cc: mozilla-dev-security-pol...@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.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Rob Stradling]

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.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Monday, February 8, 2016 1:18 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: New requirement: certlint testing

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_abou
t_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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



___
dev-security-policy mailing list
dev-security-policy@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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kathleen Wilson]

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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Jakob Bohm]

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=buypass...@lists.mozilla.org]
 On Behalf Of Kurt Roeckx
Sent: 9. februar 2016 17:58
To: Medin, Steven
Cc: mozilla-dev-security-pol...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[rafamdn]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Erwann Abalea]

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:
> > On 2/8/16 12:18 PM, 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, if you have feedback or questions about these new tests, please add
> >> them here.
> >>
> >> Thanks,
> >> Kathleen
> >
> > 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.
> 
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New requirement: certlint testing

[Medin, Steven]

How does the diffusion of early toBeSigned entropy create value for an event
performed once? 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+steve.medin=verizonbusiness@lists.mo
zilla.org] On Behalf Of Kurt Roeckx
Sent: Monday, February 08, 2016 4:32 PM
To: Kathleen Wilson
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New requirement: certlint testing

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Peter Bowen]

On Tue, Feb 9, 2016 at 6:55 AM, Erwann Abalea  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Matt Palmer]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 12:22 PM, Kathleen Wilson wrote:

On 2/8/16 12:18 PM, 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, if you have feedback or questions about these new tests, please add
them here.

Thanks,
Kathleen



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





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








___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 1:07 PM, Peter Bowen wrote:

On Mon, Feb 8, 2016 at 12:18 PM, Kathleen Wilson  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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kurt Roeckx]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 12:18 PM, 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, if you have feedback or questions about these new tests, please add
them here.

Thanks,
Kathleen



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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kurt Roeckx]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 2:36 PM, Kurt Roeckx wrote:

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




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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Peter Bowen]

On Mon, Feb 8, 2016 at 2:46 PM, Kathleen Wilson  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)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 1:36 PM, Kurt Roeckx wrote:

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




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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy