Re: Certigna Root Renewal Request

2018-10-24 Thread Wayne Thayer via dev-security-policy 
On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/24/2018 1:07 PM, Wayne Thayer wrote:
> > On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
> >>> I believe that the discussion over Certigna's reported CAA misissuance
> >>> [1][2] has reached an end, even though some questions remain
> unanswered.
> >> If
> >>> anyone has additional comments or concerns about this inclusion
> request,
> >>> please respond by Friday 26-October. This request [3] has been in
> >>> discussion since April 2017 and I would like to bring it to a
> conclusion
> >>> soon.
> >>>
> >>> - Wayne
> >>>
> >>> [1]
> >>>
> >>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
> >>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
> >>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
> >>>
> >>
> >> If there remain unresolved issues, should not approval be withheld?
> >>
> >> Certigna has completed their remediation, but a large number of
> questions
> > were asked during the discussion of the misissuance. I think it is fair
> to
> > say that Certigna was unwilling or unable to answer many of them, and
> when
> > this became apparent, I asked for the questioning to stop. Therefore, I
> > consider the issue to be resolved, but not necessarily resolved to our
> > satisfaction.
> >
>
> If Mozilla is not satisfied with how the misissuance was resolved, why
> would the root be included in Mozilla's NSS?
>
> It's fairly common for a CA to fail to meet our expectations for root
cause analysis, and I suspect that we would tolerate this one if it had
been discovered, say, a year ago rather than during the inclusion
discussion. I'm not arguing for ignoring it, but when I consider the
entirety of the evidence presented, it's not obvious to me that this should
be rejected either. That's part of the reason why I asked for additional
comments.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certigna Root Renewal Request

2018-10-24 Thread David E. Ross via dev-security-policy 
On 10/24/2018 1:07 PM, Wayne Thayer wrote:
> On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
>>> I believe that the discussion over Certigna's reported CAA misissuance
>>> [1][2] has reached an end, even though some questions remain unanswered.
>> If
>>> anyone has additional comments or concerns about this inclusion request,
>>> please respond by Friday 26-October. This request [3] has been in
>>> discussion since April 2017 and I would like to bring it to a conclusion
>>> soon.
>>>
>>> - Wayne
>>>
>>> [1]
>>>
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
>>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
>>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
>>>
>>
>> If there remain unresolved issues, should not approval be withheld?
>>
>> Certigna has completed their remediation, but a large number of questions
> were asked during the discussion of the misissuance. I think it is fair to
> say that Certigna was unwilling or unable to answer many of them, and when
> this became apparent, I asked for the questioning to stop. Therefore, I
> consider the issue to be resolved, but not necessarily resolved to our
> satisfaction.
> 

If Mozilla is not satisfied with how the misissuance was resolved, why
would the root be included in Mozilla's NSS?

-- 
David E. Ross


Too often, Twitter is a source of verbal vomit.  Examples include Donald
Trump, Roseanne Barr, and Elon Musk.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certigna Root Renewal Request

2018-10-24 Thread Wayne Thayer via dev-security-policy 
On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/23/2018 11:45 AM, Wayne Thayer wrote:
> > I believe that the discussion over Certigna's reported CAA misissuance
> > [1][2] has reached an end, even though some questions remain unanswered.
> If
> > anyone has additional comments or concerns about this inclusion request,
> > please respond by Friday 26-October. This request [3] has been in
> > discussion since April 2017 and I would like to bring it to a conclusion
> > soon.
> >
> > - Wayne
> >
> > [1]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
> >
>
> If there remain unresolved issues, should not approval be withheld?
>
> Certigna has completed their remediation, but a large number of questions
were asked during the discussion of the misissuance. I think it is fair to
say that Certigna was unwilling or unable to answer many of them, and when
this became apparent, I asked for the questioning to stop. Therefore, I
consider the issue to be resolved, but not necessarily resolved to our
satisfaction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-24 Thread Wayne Thayer via dev-security-policy 
I'm with Jakob on this, but the point is moot because Kathleen chose not to
adopt that suggestion. Instead, using "no stipulation" is a SHOULD NOT
until we update the root store policy. I would encourage CAs to update
their CPSs proactively to comply with this, but there isn't yet a deadline.

- Wayne

On Wed, Oct 24, 2018 at 7:25 AM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> That may be true, but I don't see any upside for using that date.  If you
> need
> to make a minor CPS update in early January for any reason, you now have
> additional work.
>
> I think late December policy changes should be avoided as a general rule.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy  >
> > On Behalf Of Jakob Bohm via dev-security-policy
> > Sent: Wednesday, October 24, 2018 9:44 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Cc: Jakob Bohm 
> > Subject: Re: What does "No Stipulation" mean, and when is it OK to use
> it in
> > CP/CPS?
> >
> > On 24/10/2018 00:08, Tim Hollebeek wrote:
> > > I agree with you, but December 31 is a particularly horrible compliance
> > deadline.  Perhaps January 31?
> > >
> >
> > Note that the requirement applies only to CP/CPS dated after that date.
> > So it is really Dec 31 + the time until the CP/CPS is updated for some
> other
> > reason.  This is different than many other policy requirements, and a
> > welcome reduction in administrative overhead for all concerned (including
> > root programs and relying parties).
> >
> > For example, it a CA updated their CP/CPS in August 2018 to comply with
> > new BRs, and again in May 2019 due to annual review, they need not comply
> > until May 2019.
> >
> > >
> > >> -Original Message-
> > >> From: dev-security-policy
> > >>  On Behalf Of Wayne
> > >> Thayer via dev-security-policy
> > >> Sent: Monday, October 22, 2018 6:00 PM
> > >> To: Kathleen Wilson 
> > >> Cc: mozilla-dev-security-policy
> > >> 
> > >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> > >> use it in CP/CPS?
> > >>
> > >> Having given this some more thought, I suggest the following changes:
> > >>
> > >> ...
> > >>
> > >> * Finally, I think we need some effective date for these as required
> > practices.
> > >> One approach would be to require compliance for any CP/CPS dated
> > >> after Dec 31, 2018.
> > >>
> > >> - Wayne
> > >>
> > >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> > >> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > >>
> > >>> I have updated the section as follows:
> > >>> - Removed the sentence that was trying to limit the use of "No
> > >>> Stipulation". Hopefully the clarification about what these words
> > >>> mean is sufficient.
> > >>> - Added bullet points
> > >>> - Added "Sections MUST not be left blank. ..."
> > >>>
> > >>>
> > >>>
> > >> https://clicktime.symantec.com/a/1/Xh-
> > rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> > >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> > WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> > >> UBJ2Lqfz4GYYK9b1-
> > 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> > >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> > PUFpXdUPJHpMF3mizDn82r
> > >>
> > k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> > WaoM-
> > >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> > oCmWpmJtDsMG
> > >>
> > HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> > QfVhB_kA
> > >> _fCU3vcSLkeOXiJOLq-
> > YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=htt
> > >>
> > ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> > ices%
> > >> 23CP.2FCPS
> > >>> _Structured_According_to_RFC_3647
> > >>>
> > >>>
> > >>> I continue to appreciate your feedback on this new section.
> > >>>
> >
> >
> > Enjoy
> >
> > Jakob
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-24 Thread Tim Hollebeek via dev-security-policy 
That may be true, but I don't see any upside for using that date.  If you need
to make a minor CPS update in early January for any reason, you now have
additional work.

I think late December policy changes should be avoided as a general rule.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 24, 2018 9:44 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Jakob Bohm 
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> 
> On 24/10/2018 00:08, Tim Hollebeek wrote:
> > I agree with you, but December 31 is a particularly horrible compliance
> deadline.  Perhaps January 31?
> >
> 
> Note that the requirement applies only to CP/CPS dated after that date.
> So it is really Dec 31 + the time until the CP/CPS is updated for some other
> reason.  This is different than many other policy requirements, and a
> welcome reduction in administrative overhead for all concerned (including
> root programs and relying parties).
> 
> For example, it a CA updated their CP/CPS in August 2018 to comply with
> new BRs, and again in May 2019 due to annual review, they need not comply
> until May 2019.
> 
> >
> >> -Original Message-
> >> From: dev-security-policy
> >>  On Behalf Of Wayne
> >> Thayer via dev-security-policy
> >> Sent: Monday, October 22, 2018 6:00 PM
> >> To: Kathleen Wilson 
> >> Cc: mozilla-dev-security-policy
> >> 
> >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> >> use it in CP/CPS?
> >>
> >> Having given this some more thought, I suggest the following changes:
> >>
> >> ...
> >>
> >> * Finally, I think we need some effective date for these as required
> practices.
> >> One approach would be to require compliance for any CP/CPS dated
> >> after Dec 31, 2018.
> >>
> >> - Wayne
> >>
> >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> >> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >>
> >>> I have updated the section as follows:
> >>> - Removed the sentence that was trying to limit the use of "No
> >>> Stipulation". Hopefully the clarification about what these words
> >>> mean is sufficient.
> >>> - Added bullet points
> >>> - Added "Sections MUST not be left blank. ..."
> >>>
> >>>
> >>>
> >> https://clicktime.symantec.com/a/1/Xh-
> rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> >> UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82r
> >>
> k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> WaoM-
> >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMG
> >>
> HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> QfVhB_kA
> >> _fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=htt
> >>
> ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> ices%
> >> 23CP.2FCPS
> >>> _Structured_According_to_RFC_3647
> >>>
> >>>
> >>> I continue to appreciate your feedback on this new section.
> >>>
> 
> 
> Enjoy
> 
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> https://clicktime.symantec.com/a/1/wiu9LnSxIGejJD4uoZpqluwf3s5JsQkbpA
> XBO8_i0rw=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2F
> 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://clicktime.symantec.com/a/1/iMWW4Dv3PtBKTbZjlKIU-
> irUZprQKCSffpbwg_M87H8=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2Fl
> ists.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.moz

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-24 Thread Jakob Bohm via dev-security-policy 

On 24/10/2018 00:08, Tim Hollebeek wrote:

I agree with you, but December 31 is a particularly horrible compliance 
deadline.  Perhaps January 31?



Note that the requirement applies only to CP/CPS dated after that date.
So it is really Dec 31 + the time until the CP/CPS is updated for some
other reason.  This is different than many other policy requirements,
and a welcome reduction in administrative overhead for all concerned
(including root programs and relying parties).

For example, it a CA updated their CP/CPS in August 2018 to comply with
new BRs, and again in May 2019 due to annual review, they need not
comply until May 2019.




-Original Message-
From: dev-security-policy  On
Behalf Of Wayne Thayer via dev-security-policy
Sent: Monday, October 22, 2018 6:00 PM
To: Kathleen Wilson 
Cc: mozilla-dev-security-policy 
Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
CP/CPS?

Having given this some more thought, I suggest the following changes:

...

* Finally, I think we need some effective date for these as required practices.
One approach would be to require compliance for any CP/CPS dated after Dec
31, 2018.

- Wayne

On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I have updated the section as follows:
- Removed the sentence that was trying to limit the use of "No
Stipulation". Hopefully the clarification about what these words mean
is sufficient.
- Added bullet points
- Added "Sections MUST not be left blank. ..."




https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS

_Structured_According_to_RFC_3647


I continue to appreciate your feedback on this new section.




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: Certum CA - Unallowed key usage for EC public key (Key Encipherment)

2018-10-24 Thread Wojciech Trapczyński via dev-security-policy 
In addition to the things that I described in the Incident Report we 
have added to our periodic verification procedure the point where a 
check of "CA/B Forum lint: Summary" site from crt.sh is required at 
least every 5 days. It should help us to detect any misissuance related 
to inconsistency with RFC 5280/CABF BR.


In order to prevent such misissuances in the future we are going to add 
pre-issuance linting in the first half of 2019.


-Wojciech Trapczyński

On 12.10.2018 19:37, Wayne Thayer wrote:

Wojciech,

Thank you for the incident report. I believe it does a good job of 
explaining how you will prevent this specific problem from happening 
again, but it does not address the broader problem of misissuance and 
Certum's failure to detect it. How can the Mozilla community be assured 
that Certum will detect and prevent all types of certificate misissuance 
in the future?


- Wayne

On Wed, Oct 10, 2018 at 8:03 AM Wojciech Trapczyński via 
dev-security-policy > wrote:


Please find our incident report below.

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

  From Bugzilla bug 1495518 created by Wayne Thayer on October 1
2018 at
18:42 GMT.

2. A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.

Oct 1, 2018 18:42 GMT - The Bugzilla bug 1495518 was created.
Oct 2, 2018           - We analyzed this case and found the reason for
misissues. We started to prepare the fix. We found all affected
certificates. We informed our customers about this bug and necessity to
revoked certificates.
Oct 3, 2018 12:00 GMT - We deployed fix on production.

3. Whether your CA has stopped, or has not yet stopped, issuing
certificates with the problem. A statement that you have will be
considered a pledge to the community; a statement that you have not
requires an explanation.

Oct 3, 2018 at 12:00 GMT.

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

Total number of affected valid certificates: 43. All certificates,
except two, already have been revoked. These two certificates will be
revoked by the end of this week.

5. The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged
to CT and then list the fingerprints or crt.sh IDs, either in the
report
or as an attached spreadsheet, with one list per distinct problem.

In attachement.

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

We did not properly choose the profile name for certification request
with EC public key in our software. Instead of choose EC profile where
Key Encipherment value in Key Usage extension is disallowed we choose
RSA profile where Key Encipherment value in Key Usage extension is
allowed. The bug was not found by our tests suite because we did not
have scenario for such case.

7. List of steps your CA is taking to resolve the situation and ensure
such issuance will not be repeated in the future, accompanied with a
timeline of when your CA expects to accomplish these things.

- We have fixed our software. Now, if a certification request contains
EC public key only EC certificate profile is allowed to use.
- We have added the appropriate test case. Now, for every software
release we check that appropriate profile is chosen for given type of
public key.
- We have added an additional protection at the certificate profile
level in the CA issuing system. Now, the CA system for issuing
certificates will block the issuance of the certificate if it receives
unmatched combination of public key and profile.
___
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