Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Peter Bowen via dev-security-policy]

On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy
 wrote:
> On Thu, Jun 1, 2017 at 4:35 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 31/05/17 18:02, Matthew Hardeman wrote:
>> > Perhaps some reference to technologically incorrect syntax (i.e. an
>> incorrectly encoded certificate) being a mis-issuance?
>>
>> Well, if it's so badly encoded Firefox doesn't recognise it, we don't
>> care too much (apart from how it speaks to incompetence). If Firefox
>> does recognise it, then I'm not sure "misissuance" is the right word if
>> all the data is correct.
>>
>
> I would encourage you to reconsider this, or perhaps I've misunderstood
> your position. To the extent that Mozilla's mission includes "The
> effectiveness of the Internet as a public resource depends upon
> interoperability (protocols, data formats, content) ", the
> well-formedness and encoding directly affects Mozilla users (sites working
> in Vendors A, B, C but not Mozilla) and the broader ecosystem (sites
> Mozilla users are protected from that vendors A, B, C are not).
>
> I think considering this in the context of "CA problematic practices" may
> help make this clearer - they are all things that speak to either
> incompetence or confusion (and a generous dose of Hanlon's Razor) - but
> their compatibility issues presented both complexity and risk to Mozilla
> users.
>
> So I would definitely encourage that improper application of the protocols
> and data formats constitutes misissuance, as they directly affect
> interoperability and indirectly affect security :)

I think the policy needs to be carefully thought out here, as there is
no limitation to what can be signed with the key used to sign
certificates.   What is a malformed certificate to one person might be
a valid document to someone else.  Maybe you could disallow signing
things that are not valid ASN.1 DER?

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

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Jakob Bohm via dev-security-policy]

On 31/05/2017 18:04, Gervase Markham wrote:

It has been suggested we need a formal definition of what we consider
mis-issuance. The closest we have is currently a couple of sentence in
section 7.3:

"A certificate that includes domain names that have not been verified
according to section 3.2.2.4 of the Baseline Requirements is considered
to be mis-issued. A certificate that is intended to be used only as an
end entity certificate but includes a keyUsage extension with values
keyCertSign and/or cRLSign or a basicConstraints extension with the cA
field set to true is considered to be mis-issued."

This is clearly not an exhaustive list; one would also want to include
BR violations, RFC violations, and insufficient EV vetting, at least.

The downside of defining it is that CAs might try and rules-lawyer us in
a particular situation.

Here's some proposed text which provides more clarity while hopefully
avoiding rules-lawyering:

"The category of mis-issued certificates includes (but is not limited
to) those issued to someone who should not have received them, those
containing information which was not properly validated, those having
incorrect technical constraints, and those using algorithms other than
those permitted."



How about: Any issued certificate which violates any applicable policy,
requirement or standard, which was not requested by all its alleged
subject(s) or which should otherwise not have been issued, is by
definition mis-issued.  Policies and requirements include but are not
limited to this policy, the CCADB policy, the applicable CPS, and the
baseline requirements.  Any piece of data which technically resembles an
X.509 or PKCS#6 extended certificate, and which is signed by the CA
private key is considered an issued certificate.

(Note: I mention the ancient PKCS#6 certificate type because mis-issuing
those is still mis-issuance, even if there is no current reason to
validly issue those).

(Note: The last sentence above was phrased to try to cover semi-garbled
certificates, without accidentally banning things like CRLs and OCSP
responses).


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: Taiwan GRCA Root Renewal Request

[Kathleen Wilson via dev-security-policy]

On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote:
> On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote:
> All, 
> 
> I requested that this CA perform a BR Self Assessment, and they have attached 
> their completed BR Self Assessment to the bug here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30
> 
> Aaron has reviewed and verified the BR Self Assessment.
> 
> Therefore, I plan to approve this request from the Government of Taiwan 
> (GRCA) to include their "Government Root Certification Authority" root 
> certificate, and turn on the Websites and Email trust bits, and constrain 
> this root to *.tw. 
> 
> If there are no further concerns, then I will close this discussion and 
> recommend approval in the bug.
> 

After further consideration, I have decided to wait for the CA to provide their 
updated CP/CPS that will address all of the shortcomings that they noted in 
their BR Self Assessment that they plan to fix in the next version of their 
CP/CPS.

So, this discussion will be on hold again until I have received and reviewed 
their updated CP/CPS documents.

Thanks,
Kathleen


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

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Peter Kurrasch via dev-security-policy]

  So how about this:A proper certificate is one that...- contains the data as provided by the requester that the requester intended to use;- contains the data as provided by the issuer that the issuer intended to use;- contains data that has been properly verified by the issuer, to the extent that the data is verifiable in the first place;- uses data that is recognized as legitimate for a certificate's intended use, per the relevant standards, specifications, recommendations, ‎and policies, as well as the software products that are likely to utilize the certificate;- is suitably constructed in accordance with the relevant standards, specifications, recommendations, and policies, as appropriate; and- is produced by equipment and systems whose integrity is assured by the issuer and verified by ‎the auditors.Thus, failing one or more of the above conditions will constitute a mis-issuance situation.From: Matthew Hardeman via dev-security-policySent: Thursday, June 1, 2017 1:35 PM‎On Thursday, June 1, 2017 at 8:03:33 AM UTC-5, Gervase Markham wrote:> > My point is not that we are entirely indifferent to such problems, but> that perhaps the category of "mis-issuance" is the wrong one for such> errors. I guess it depends what we mean by "mis-issuance" - which is the> entire point of this discussion!> > So, if mis-issuance means there is some sort of security problem, then> my original definition still seems like a good one to me. If> mis-issuance means any problem where the certificate is not as it should> be, then we need a wider definition.> It was in that spirit that I raised the questions that I did.‎ I wonder if the pedant can use these arguments to call any certificate "mis-issued" under the proposed definition.  If so, I wonder if we should care if such a tortured argument might be made.> I wonder whether we need a new word for certificates which are bogus for> a non-security-related reason. "Mis-constructed"?> ___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Nick Lamb via dev-security-policy]

I think a broad definition is appropriate here. Mozilla is not obliged to do 
anything at all, much less anything drastic if it is discovered that 
mis-issuance has occurred. At most we might think it time to re-evaluate this 
policy.

Fools are endlessly inventive so a too narrow definition runs the risk of 
missing something so obvious that when inevitably a CA gets it wrong we're 
astonished to find it's not included.

One risk I do anticipate is CAs which have inadequately bound together separate 
validation steps, such as where a domain validation was done by an applicant, 
and a CSR proving control of a particular private key has been presented by an 
applicant, but it turns out they weren't actually the same applicant, so it 
will be an error to issue a certificate binding the two together.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Matthew Hardeman via dev-security-policy]

On Thursday, June 1, 2017 at 8:03:33 AM UTC-5, Gervase Markham wrote:

> 
> My point is not that we are entirely indifferent to such problems, but
> that perhaps the category of "mis-issuance" is the wrong one for such
> errors. I guess it depends what we mean by "mis-issuance" - which is the
> entire point of this discussion!
> 
> So, if mis-issuance means there is some sort of security problem, then
> my original definition still seems like a good one to me. If
> mis-issuance means any problem where the certificate is not as it should
> be, then we need a wider definition.
> 

It was in that spirit that I raised the questions that I did.

For example, when I mentioned "those containing information which was not 
properly validated", I meant to imply that in a rather tortured construction, 
taken ad absurdum, every bit and byte of that certificate is certainly 
"information" and the certificate overall most certainly contains every byte of 
itself.  Having said that, can we literally say that a certificate is only 
properly issued if quite literally every byte within it has been "validated"?  
Or are we really just talking about the certificate subject?  But not really 
because we also certainly mean that contents of certain certificate extensions, 
like SAN, contain only validated information.  At the same time, though, what 
documentation would one draw upon to assert that serial number had been 
"validated"?  Validated in this context generally means supported via 
documentation as true and correct.  The serial number is meant to contain a 
random component.  We can validate the mechanism that generated the serial numbe
 r, but we can not say that the serial number itself is validated.  If a policy 
OID is added to the certificate, is it validated in the sense that my CP/CPS 
says that I may put OID X with meaning Y there?  Or is it just a series of 
bytes which point to an OID within the OID tree assigned to my enterprise?  I 
wonder if the pedant can use these arguments to call any certificate 
"mis-issued" under the proposed definition.  If so, I wonder if we should care 
if such a tortured argument might be made.

> I wonder whether we need a new word for certificates which are bogus for
> a non-security-related reason. "Mis-constructed"?
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: StartCom issuing bogus certificates

[Inigo Barreira via dev-security-policy]

Hi

 

  
https://bugzilla.mozilla.org/attachment.cgi?id=8873408

 

  
https://bugzilla.mozilla.org/attachment.cgi?id=8873409

 

 

these are the 2 documents I tried to upload to the list, these are now in the 
bug created by Gerv at   
https://bugzilla.mozilla.org/show_bug.cgi?id=1369359

 

 

Best regards

 

Iñigo Barreira

CEO

StartCom CA Limited

 

From: Vincent Lynch [mailto:vtly...@gmail.com] 
Sent: jueves, 1 de junio de 2017 14:46
To: Eric Mill ; Gervase Markham ; Inigo 
Barreira ; Jeremy Rowley ; 
Yuhong Bao 
Cc: Kurt Roeckx ; Matthew Hardeman ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom issuing bogus certificates

 

Hi Inigo,

 

You mentioned there would be a report attached but I believe you forgot to send 
it? 

 

Can you upload the report and provide a URL? I believe that's the 'best 
practice' for sharing files here as it allows non-subscribers to access the 
file via the Google Groups archive.

 

-Vincent

 

On Thu, Jun 1, 2017 at 6:40 AM Inigo Barreira via dev-security-policy 
 > wrote:

Hi all,

Firstly I´d like to apologize for not having answering before and for
posting an initial response that was not correct not accurate and not
related what it´s being discussed right now. It was my fault for not having
checked before with my team, which is in China and they are 6 hours ahead,
but was my first reaction when saw test in the SAN. So, sorry for this.

In fact, the "issue" was due for implementing the CT log. Recently one
customer asked why we weren´t logging our certificates in the CT logs, which
we were doing it but with some problems because of the great firewall. So,
we were talking with Primekey and provided a solution to implement in our
system. We did it yesterday and for checking it, we created those "fake"
certificates for testing, which were revoked inmediately.
Attached there´s a report in which we explain all that has happened. And
also some screenshots.
In this report also indicate what remeditation steps we´ve already done to
avoid these issues happen again in the future.

We´ve also realized that the CRL generation didn´t work as supposed because
didn´t generate a new CRL when those certificates were revoked  but in the
next update. We are dealing with Primekey to know what has happened. The
OCSP response instead was correct and showed the certificates as revoked.

For some other comments/suggestions posted in this thread I´d like to say
that:

- this incident is not related to the "real" issuance system through our CMS
system in which all domains are verified
- these certs were issued and revoked inmediately as they were only for
testing. I know it wasn´t a good decission
- regarding my initial response for test URLs, those are going to be
generated under our own website, like valid.startcomca.com 
 ,
revoked.startcomca.com  
- and for those other certs in crt.sh, those are revoked but there are four
that were not issued because the connection with the CT failed and for some
reason are showed in the crt.sh. We´re contacting Primekey to know what has
happened but it seems to be related with the Startcom log, which didn´t
logged it because it failed and google logs, which did it, so maybe is a
configuration issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo 
 =startcomca@lists.mozilla.org 
 ]
On Behalf Of Gervase Markham via dev-security-policy
Sent: jueves, 1 de junio de 2017 10:27
To: Yuhong Bao  >; 
Eric Mill  >;
Jeremy Rowley  >
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
 ; Kurt Roeckx
 >; Matthew Hardeman 
 >
Subject: Re: StartCom issuing bogus certificates

On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com  
>  though

How would you like it if a CA decided there was nothing important on your
website and so decided it was OK to misissue certificates for it?

This requirement is a positive requirement ("must have validated domain
ownership or control by applicant"), not a negative requirement ("domain
must not 

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

On 01/06/17 14:22, Doug Beattie wrote:
> If this is the case, then in what cases do you see 2-factor auth being a 
> requirement where it was not before?

Well, Mozilla policy didn't require that all RA accounts had
multi-factor, only those directly capable of causing certificate
issuance. Maybe there was some other requirement somewhere which means
this addition is redundant?

An example of someone who didn't require it before who requires it now
would be someone who did EV research into the correctness of the company
information as supplied by the applicant, and marked it as "confirmed"
in the system. This is "performing a validation function", but it's not
"directly causing certificate issuance".

Gerv

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

RE: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Doug Beattie via dev-security-policy]

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, June 1, 2017 8:46 AM
To: Gervase Markham 
Cc: Doug Beattie ; mozilla-dev-security-policy 

Subject: Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

> > "enforce multi-factor authentication for all accounts capable of 
> > directly causing certificate issuance"
> >
> > to
> >
> > "enforce multi-factor authentication for all accounts capable of 
> > causing certificate issuance or performing validation functions"

> > Does anyone have suggestions as to how we can word this provision to
> > make this distinction?

> Do you think it's a valid reading to suggest that the e-mail confirmation 
> link is, in fact, performing > a validation function?

> That is, I can appreciate the tortured reading that results in this - and I 
> can appreciate the desire 
> for greater clarity - but I'm not sure it's worth expending significant 
> effort on. In the worst case, a 
> CA who reads it like Doug suggests will result in a more secure system 
> (vis-a-vis the discussion in 
> the CA/Browser Forum regarding email scanning devices that 'click' on links).

Yea, I didn’t really think that 2-factor auth needed to apply to this, but I 
don’t see how it applies to any of the automated domain validation processes 
either.  When a user requests the validation of a domain we'll provide them a 
Random Number via email, or one that they need to incorporate into DNS, Test 
Certificate or web site change.  Once the email is received or the random value 
is in place, the CA checks for this (maybe upon being asked by the partner or 
applicant).  I don’t see any place in these processes where 2-factor auth is 
applicable. Even in a managed account where an authenticated  Applicant says: 
"I want to add this domain to my account" and we provide a Random Number for 
them to use to demonstrate control I don’t see a need for 2-factor auth for 
that "account".

I understand the increased importance on domain validation, but I'm not clear 
how we map this to domain validation at all, except perhaps for doing it 
manually via who-is by an RA (and RAs already need 2-factor auth).

If this is the case, then in what cases do you see 2-factor auth being a 
requirement where it was not before?

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

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Gervase Markham via dev-security-policy]

On 01/06/17 13:49, Ryan Sleevi wrote:
> I would encourage you to reconsider this, or perhaps I've misunderstood
> your position. To the extent that Mozilla's mission includes "The
> effectiveness of the Internet as a public resource depends upon
> interoperability (protocols, data formats, content) ", the
> well-formedness and encoding directly affects Mozilla users (sites working
> in Vendors A, B, C but not Mozilla) and the broader ecosystem (sites
> Mozilla users are protected from that vendors A, B, C are not).

My point is not that we are entirely indifferent to such problems, but
that perhaps the category of "mis-issuance" is the wrong one for such
errors. I guess it depends what we mean by "mis-issuance" - which is the
entire point of this discussion!

So, if mis-issuance means there is some sort of security problem, then
my original definition still seems like a good one to me. If
mis-issuance means any problem where the certificate is not as it should
be, then we need a wider definition.

I wonder whether we need a new word for certificates which are bogus for
a non-security-related reason. "Mis-constructed"?

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

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

On 01/06/17 13:45, Ryan Sleevi wrote:
> The reason why I don't think it's a valid reasoning is that if we accept
> that this provision in the policy could be read to cover such emails, then
> we're implicitly agreeing that the act of clicking that email is performing
> a validation function pursuant to 3.2.2.4 of the Baseline Requirements.

Well, yes, probably. This text is in the Mozilla policy and the above is
in the Baseline Requirements, but I can see how this logic works.

> Ergo, every customer of that CA who uses that method is acting as a
> Delegated Third Party, performing the validation functions of 3.2.2.4 -
> since, by logical extension, they're performing the validation function of
> 3.2.2.4 on their account - and all the attendant mess that it entails.

That's a good point.

Perhaps this leads to the solution? We say:

"enforce multi-factor authentication for all accounts capable of causing
certificate issuance or performing RA or DTP functions as defined by the
Baseline Requirements"

?

Gerv

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

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Ryan Sleevi via dev-security-policy]

On Thu, Jun 1, 2017 at 4:35 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 31/05/17 18:02, Matthew Hardeman wrote:
> > Perhaps some reference to technologically incorrect syntax (i.e. an
> incorrectly encoded certificate) being a mis-issuance?
>
> Well, if it's so badly encoded Firefox doesn't recognise it, we don't
> care too much (apart from how it speaks to incompetence). If Firefox
> does recognise it, then I'm not sure "misissuance" is the right word if
> all the data is correct.
>

I would encourage you to reconsider this, or perhaps I've misunderstood
your position. To the extent that Mozilla's mission includes "The
effectiveness of the Internet as a public resource depends upon
interoperability (protocols, data formats, content) ", the
well-formedness and encoding directly affects Mozilla users (sites working
in Vendors A, B, C but not Mozilla) and the broader ecosystem (sites
Mozilla users are protected from that vendors A, B, C are not).

I think considering this in the context of "CA problematic practices" may
help make this clearer - they are all things that speak to either
incompetence or confusion (and a generous dose of Hanlon's Razor) - but
their compatibility issues presented both complexity and risk to Mozilla
users.

So I would definitely encourage that improper application of the protocols
and data formats constitutes misissuance, as they directly affect
interoperability and indirectly affect security :)


>
> > How far does "those containing information which was not properly
> validated" go?  Does that leave the opportunity for someone's tortured
> construction of the rule to suggest that a certificate that everyone agrees
> is NOT mis-issued is in fact technically mis-issued?
>
> Certs containing data which is not properly validated, which
> nevertheless happens by chance to be correct, are still mis-issued,
> because they are BR-non-compliant. It may be hard to detect this case,
> but I think it should be in the definition. A CA has a positive duty to
> validate/revalidate all data within the timescales established.
>

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

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Ryan Sleevi via dev-security-policy]

On Thu, Jun 1, 2017 at 6:52 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Doug,
>
> On 01/06/17 10:54, Doug Beattie wrote:
> > Can you give some examples of validation functions that need to be
> enforced by multifactor authentication?  There are some that I don't think
> can be done using multi-factor authentication, such as domain validation
> via email (the link to confirm the domain can't be protected by
> multi-factor auth).
>
> This is a good point; I think we've been unclear here. The aim was to
> target CA or RA employees sitting at computers and logging in to perform
> validation functions such as entering data. It wasn't designed to
> require email domain validation link-clicking to be multi-factor, or for
> that matter to require someone logging into their account with their CA
> to say "please re-issue my certificate for this already-validated
> domain" to require multi-factor.
>
> Does anyone have suggestions as to how we can word this provision to
> make this distinction?


Do you think it's a valid reading to suggest that the e-mail confirmation
link is, in fact, performing a validation function?

That is, I can appreciate the tortured reading that results in this - and I
can appreciate the desire for greater clarity - but I'm not sure it's worth
expending significant effort on. In the worst case, a CA who reads it like
Doug suggests will result in a more secure system (vis-a-vis the discussion
in the CA/Browser Forum regarding email scanning devices that 'click' on
links).

The reason why I don't think it's a valid reasoning is that if we accept
that this provision in the policy could be read to cover such emails, then
we're implicitly agreeing that the act of clicking that email is performing
a validation function pursuant to 3.2.2.4 of the Baseline Requirements.
Ergo, every customer of that CA who uses that method is acting as a
Delegated Third Party, performing the validation functions of 3.2.2.4 -
since, by logical extension, they're performing the validation function of
3.2.2.4 on their account - and all the attendant mess that it entails.

So while I can appreciate the question, and I can appreciate why it's
raised, I would think that if someone who wanted to make that
interpretation extended the argument through its logical conclusion, it
would naturally reveal itself as an invalid interpretation - or, ideally,
one in which other CAs will question, and we can point back to this thread.

Put differently, I think it's absolutely fantastic that Doug has raised
this question, and I think all CAs should raise any such questions of
interpretation on the list, so they can be explored, answered, and
clarified - as you have - but I'm not sure that it should be incumbent on
the policy to clarify it, especially if the (mis)interpretation results in
greater rigor, rather than less :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom issuing bogus certificates

[Vincent Lynch via dev-security-policy]

Hi Inigo,

You mentioned there would be a report attached but I believe you forgot to
send it?

Can you upload the report and provide a URL? I believe that's the 'best
practice' for sharing files here as it allows non-subscribers to access the
file via the Google Groups archive.

-Vincent

On Thu, Jun 1, 2017 at 6:40 AM Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi all,
>
> Firstly I´d like to apologize for not having answering before and for
> posting an initial response that was not correct not accurate and not
> related what it´s being discussed right now. It was my fault for not having
> checked before with my team, which is in China and they are 6 hours ahead,
> but was my first reaction when saw test in the SAN. So, sorry for this.
>
> In fact, the "issue" was due for implementing the CT log. Recently one
> customer asked why we weren´t logging our certificates in the CT logs,
> which
> we were doing it but with some problems because of the great firewall. So,
> we were talking with Primekey and provided a solution to implement in our
> system. We did it yesterday and for checking it, we created those "fake"
> certificates for testing, which were revoked inmediately.
> Attached there´s a report in which we explain all that has happened. And
> also some screenshots.
> In this report also indicate what remeditation steps we´ve already done to
> avoid these issues happen again in the future.
>
> We´ve also realized that the CRL generation didn´t work as supposed because
> didn´t generate a new CRL when those certificates were revoked  but in the
> next update. We are dealing with Primekey to know what has happened. The
> OCSP response instead was correct and showed the certificates as revoked.
>
> For some other comments/suggestions posted in this thread I´d like to say
> that:
>
> - this incident is not related to the "real" issuance system through our
> CMS
> system in which all domains are verified
> - these certs were issued and revoked inmediately as they were only for
> testing. I know it wasn´t a good decission
> - regarding my initial response for test URLs, those are going to be
> generated under our own website, like valid.startcomca.com,
> revoked.startcomca.com
> - and for those other certs in crt.sh, those are revoked but there are four
> that were not issued because the connection with the CT failed and for some
> reason are showed in the crt.sh. We´re contacting Primekey to know what has
> happened but it seems to be related with the Startcom log, which didn´t
> logged it because it failed and google logs, which did it, so maybe is a
> configuration issue.
>
> Best regards
>
> Iñigo Barreira
> CEO
> StartCom CA Limited
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org
> ]
> On Behalf Of Gervase Markham via dev-security-policy
> Sent: jueves, 1 de junio de 2017 10:27
> To: Yuhong Bao ; Eric Mill ;
> Jeremy Rowley 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Kurt Roeckx
> ; Matthew Hardeman 
> Subject: Re: StartCom issuing bogus certificates
>
> On 01/06/17 01:48, Yuhong Bao wrote:
> > I don't think there is anything important on example.com though
>
> How would you like it if a CA decided there was nothing important on your
> website and so decided it was OK to misissue certificates for it?
>
> This requirement is a positive requirement ("must have validated domain
> ownership or control by applicant"), not a negative requirement ("domain
> must not have anything important on it").
>
> Gerv
> ___
> 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
>
-- 
Vincent Lynch
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham via dev-security-policy]

Hi Doug,

On 01/06/17 10:54, Doug Beattie wrote:
> Can you give some examples of validation functions that need to be enforced 
> by multifactor authentication?  There are some that I don't think can be done 
> using multi-factor authentication, such as domain validation via email (the 
> link to confirm the domain can't be protected by multi-factor auth).

This is a good point; I think we've been unclear here. The aim was to
target CA or RA employees sitting at computers and logging in to perform
validation functions such as entering data. It wasn't designed to
require email domain validation link-clicking to be multi-factor, or for
that matter to require someone logging into their account with their CA
to say "please re-issue my certificate for this already-validated
domain" to require multi-factor.

Does anyone have suggestions as to how we can word this provision to
make this distinction?

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

RE: StartCom issuing bogus certificates

[Inigo Barreira via dev-security-policy]

Hi all,

Firstly I´d like to apologize for not having answering before and for
posting an initial response that was not correct not accurate and not
related what it´s being discussed right now. It was my fault for not having
checked before with my team, which is in China and they are 6 hours ahead,
but was my first reaction when saw test in the SAN. So, sorry for this.

In fact, the "issue" was due for implementing the CT log. Recently one
customer asked why we weren´t logging our certificates in the CT logs, which
we were doing it but with some problems because of the great firewall. So,
we were talking with Primekey and provided a solution to implement in our
system. We did it yesterday and for checking it, we created those "fake"
certificates for testing, which were revoked inmediately.
Attached there´s a report in which we explain all that has happened. And
also some screenshots.
In this report also indicate what remeditation steps we´ve already done to
avoid these issues happen again in the future.

We´ve also realized that the CRL generation didn´t work as supposed because
didn´t generate a new CRL when those certificates were revoked  but in the
next update. We are dealing with Primekey to know what has happened. The
OCSP response instead was correct and showed the certificates as revoked.

For some other comments/suggestions posted in this thread I´d like to say
that:

- this incident is not related to the "real" issuance system through our CMS
system in which all domains are verified
- these certs were issued and revoked inmediately as they were only for
testing. I know it wasn´t a good decission
- regarding my initial response for test URLs, those are going to be
generated under our own website, like valid.startcomca.com,
revoked.startcomca.com
- and for those other certs in crt.sh, those are revoked but there are four
that were not issued because the connection with the CT failed and for some
reason are showed in the crt.sh. We´re contacting Primekey to know what has
happened but it seems to be related with the Startcom log, which didn´t
logged it because it failed and google logs, which did it, so maybe is a
configuration issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: jueves, 1 de junio de 2017 10:27
To: Yuhong Bao ; Eric Mill ;
Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Kurt Roeckx
; Matthew Hardeman 
Subject: Re: StartCom issuing bogus certificates

On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com though

How would you like it if a CA decided there was nothing important on your
website and so decided it was OK to misissue certificates for it?

This requirement is a positive requirement ("must have validated domain
ownership or control by applicant"), not a negative requirement ("domain
must not have anything important on it").

Gerv
___
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: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Sent: Wednesday, May 31, 2017 7:24 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth
> >
> > "enforce multi-factor authentication for all accounts capable of
> > directly causing certificate issuance"
> >
> > to
> >
> > "enforce multi-factor authentication for all accounts capable of
> > causing certificate issuance or performing validation functions"

Can you give some examples of validation functions that need to be enforced by 
multifactor authentication?  There are some that I don't think can be done 
using multi-factor authentication, such as domain validation via email (the 
link to confirm the domain can't be protected by multi-factor auth).


> Implemented as specced.
> 
> Gerv
> 
> ___
> 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: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Gervase Markham via dev-security-policy]

On 31/05/17 18:02, Matthew Hardeman wrote:
> Perhaps some reference to technologically incorrect syntax (i.e. an 
> incorrectly encoded certificate) being a mis-issuance?

Well, if it's so badly encoded Firefox doesn't recognise it, we don't
care too much (apart from how it speaks to incompetence). If Firefox
does recognise it, then I'm not sure "misissuance" is the right word if
all the data is correct.

> How far does "those containing information which was not properly validated" 
> go?  Does that leave the opportunity for someone's tortured construction of 
> the rule to suggest that a certificate that everyone agrees is NOT mis-issued 
> is in fact technically mis-issued?

Certs containing data which is not properly validated, which
nevertheless happens by chance to be correct, are still mis-issued,
because they are BR-non-compliant. It may be hard to detect this case,
but I think it should be in the definition. A CA has a positive duty to
validate/revalidate all data within the timescales established.

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

Re: StartCom issuing bogus certificates

[Gervase Markham via dev-security-policy]

On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com though

How would you like it if a CA decided there was nothing important on
your website and so decided it was OK to misissue certificates for it?

This requirement is a positive requirement ("must have validated domain
ownership or control by applicant"), not a negative requirement ("domain
must not have anything important on it").

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