Closed Bug 1391056 Opened 2 years ago Closed 2 years ago

NetLock: Non-BR-Compliant Certificate Issuance

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kwilson, Assigned: varga.viktor)

References

Details

(Whiteboard: [ca-compliance])

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) 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.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ
Dear Kathleen,

Our answers are after the questions:

> 1) How your CA first became aware of the problems listed below (e.g. via a
> Problem Report, via the discussion in mozilla.dev.security.policy, or via
> this Bugzilla Bug), and the date.

After the Android Chrome 58 release the owner of one of the certificate affected reported problems which resulted 
at us search for problem. We found out, that the problem cames from the accented domains included into the certificate, and we look after the valid certificates with the same problem and found the other one. Until that errpr report, none of the browser reported problem on those certificates.
Both customers were contacted for replace the certificate for them, this was finished today, the valid misissued certificates were revoked also.

> 2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates
> with the problems listed below.

Together with the freshly implemented CAA validation until 07-20 we implemented additional measures to filter the DNS names including characters not allowed in dnsNames.


> 3) Complete list of certificates that your CA finds with each of the listed
> issues during the remediation process. The recommended way to handle this is
> to ensure each certificate is logged to CT and then attach a CSV
> file/spreadsheet of the fingerprints or crt.sh IDs, with one list per
> distinct problem.

All of the affected cerficates were already listed here:
https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit#gid=1586469978

> 4) Summary of the problematic certificates. For each problem listed below:
> number of certs, date first and last certs with that problem were issued.

4 certs, first was issued at 2015-12-17 15:40:02 last was issued at 2017-05-29 14:18:26

> 5) Explanation about how and why the mistakes were made, and not caught and
> fixed earlier.

The main causes to not caught earlier:
1. There was no clue about the mistake. Until the Android Chrome 58 update every browser worked fine with this error
2. The low volume of IDN certificates caused, that they were not targeted by the spot checks.


After we caught we fixed it ASAP, then we worked on the replacement of the certificates together with the customers.

> 6) 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 already implemented technical changes and also operational changes (modification of the CPs, CPSes and the internal processing policies) until 07-20, when  

> 7) Regular updates to confirm when those steps have been completed.

They were completed.

> Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which
> states:
> “The CA SHALL revoke a Certificate within 24 hours if one or more of the
> following occurs: …
> 9. The CA is made aware that the Certificate was not issued in accordance
> with these Requirements or the CA’s Certificate Policy or Certification
> Practice Statement; 
> 10. The CA determines that any of the information appearing in the
> Certificate is inaccurate or misleading; …
> 14. Revocation is required by the CA’s Certificate Policy and/or
> Certification Practice Statement; or 
> 15. The technical content or format of the Certificate presents an
> unacceptable risk to Application Software Suppliers or Relying Parties (e.g.
> the CA/Browser Forum might determine that a deprecated
> cryptographic/signature algorithm or key size presents an unacceptable risk
> and that such Certificates should be revoked and replaced by CAs within a
> given period of time).
> 
> However, it is not our intent to introduce additional problems by forcing
> the immediate revocation of certificates that are not BR compliant when they
> do not pose an urgent security concern. Therefore, we request that your CA
> perform careful analysis of the situation. If there is justification to not
> revoke the problematic certificates, then explain those reasons and provide
> a timeline for when the bulks of the certificates will expire or be
> revoked/replaced. 
> 
> We expect that your forthcoming audit statements will indicate the findings
> of these problems. If your CA will not be revoking the certificates within
> 24 hours in accordance with the BRs, then that will also need to be listed
> as a finding in your CA’s BR audit statement.
> 
> We expect that your CA will work with your auditor (and supervisory body, as
> appropriate) and the Root Store(s) that your CA participates in to ensure
> your analysis of the risk and plan of remediation is acceptable. If your CA
> will not be revoking the problematic certificates as required by the BRs,
> then we recommend that you also contact the other root programs that your CA
> participates in to acknowledge this non-compliance and discuss what
> expectations their Root Programs have with respect to these certificates.

Unfortunately we missed this, but when we got it, we revoked them in 24 hours.

> The problems reported for your CA in the mozilla.dev.security.policy forum
> are as follows:
> 
> ** Failure to respond within 24 hours after Problem Report submitted
> https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/
> w2AMK81jAQAJ
> The problems were reported via your CA’s Problem Reporting Mechanism as
> listed here:
> https://ccadb-public.secure.force.com/mozilla/CAInformationReport
> Therefore, if this is the first time you have received notice of the
> problem(s) listed below, please review and fix your CA’s Problem Reporting
> Mechanism to ensure that it will work the next time someone reports a
> problem like this.

We looked after it and it includes revocation contact info extracted from the PDS. We will update those fields in CADB.
Also we will look after where we should also report this incident.

Sincerely yours,
Viktor Varga,
Netlock
Hi Viktor,

> We will update those fields in CADB.

I believe these fields need to be updated by a root store; I think that if you post the updated information here, Kathleen will be able to add it.

Gerv
I emailed a problem report about these certificates, can you please investigate and explain why it was not received?

Here are the relevant message headers:

  From: Jonathan Rudenberg <jonathan@titanous.com>
  Subject: Misissuance - invalid characters in certificate SAN dnsNames
  Message-Id: <CE3447F6-31A3-4A5C-934E-E583D0A46AD6@titanous.com>
  Date: Mon, 7 Aug 2017 21:04:30 -0400
  To: visszavonas@netlock.hu
(In reply to Gervase Markham [:gerv] from comment #2)
> Hi Viktor,
> 
> > We will update those fields in CADB.
> 
> I believe these fields need to be updated by a root store; I think that if
> you post the updated information here, Kathleen will be able to add it.
> 
> Gerv

Thank you, you have right its not editable.

(In reply to Jonathan Rudenberg from comment #3)
> I emailed a problem report about these certificates, can you please
> investigate and explain why it was not received?
> 
> Here are the relevant message headers:
> 
>   From: Jonathan Rudenberg <jonathan@titanous.com>
>   Subject: Misissuance - invalid characters in certificate SAN dnsNames
>   Message-Id: <CE3447F6-31A3-4A5C-934E-E583D0A46AD6@titanous.com>
>   Date: Mon, 7 Aug 2017 21:04:30 -0400
>   To: visszavonas@netlock.hu

We got those reply, and I answered it to you a few minutes ago.
Unfortunately, your mail not triggered the bell in the heads, and it waited until I got back from abroad. 

We will train our customers service, about the fast escalation of unusual emails on this mailbox on the next week.

Sincerely yours,
Viktor Varga,
Netlock
Dear Kathleen,
Dear Gerv,

I checked, and problem reporting addresses are correct and accessible.

Should this field include the PDS contacts section, 
or should it include a CCADB specific problem reporting mechanism, which can be differ from that.
(In the second case I can give a shorter way (direct phone or something)

Sincerely yours, 
Viktor Varga 
Netlock
(In reply to Varga Viktor from comment #5)
> I checked, and problem reporting addresses are correct and accessible.
> Should this field include the PDS contacts section, 
> or should it include a CCADB specific problem reporting mechanism, which can
> be differ from that.


The "Problem Reporting Mechanism" field corresponds to how the general public should report problems to your CA.
Thank you Kathleen,

Then we would like to keep the original entries.

What we do until now:
1. we educated our collegues to alert earlier, when they got unusual emails, what they should do
2. we educated our collegues about the specialities of IDNs in certificates
3. identified in the code, how can be this possible (another type verification is needed because the different character set size  of the CN and SAN in the case of IDNs)
4. added code to verify invalid chars in SSL requests at the verification phase

Yours,
Viktor Varga
(In reply to Varga Viktor from comment #1)
> > 5) Explanation about how and why the mistakes were made, and not caught and
> > fixed earlier.
> 
> The main causes to not caught earlier:
> 1. There was no clue about the mistake. Until the Android Chrome 58 update
> every browser worked fine with this error
> 2. The low volume of IDN certificates caused, that they were not targeted by
> the spot checks.
> 
> 
> After we caught we fixed it ASAP, then we worked on the replacement of the
> certificates together with the customers.

Thanks for responding. I think it's still necessary to provide additional detail.

That is, we can look at the problem from two dimensions: The problem itself, and the systemic issues that allowed the problem to manifest. Your description focuses on the resolution of the problem, but doesn't indicate any systemic changes have been made. As a consequence, it does not help the community feel that your CA has taken steps to reduce the risk of future violations (of any requirement) in the future. That is, one dimension is "Did you fix the bug", but another dimension is "How was the bug introduced, why was it not detected, and what steps are you taking to prevent future bugs"

To understand how you might approach this problem, consider https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were already in place (and with substantial detail), where there were controls missing or mistakes made, details about the steps being taken (e.g. "We fixed the bug" is not sufficient detail to understand), and a holistic, systemic awareness of how the CA is managed and the opportunities for errors.

In this particular case:
- As you noted, you failed to detect this issue until a customer reported a compatibility issue. Yet none of your remediation plans include steps to improve detection tooling. Why is that?
- The failure to reply in a timely fashion was due to human factors. Yet it sounds like your proposed remediation is to still rely on human factors (to escalate the issue). Did you consider any technical solutions to ensure proper monitoring and alerting for problem reports?
- You indicated that 'another type verification is needed because the different character set size of the CN and the SAN in the case of IDNs'. I'm not sure that I fully understand what you're trying to say. Can you please describe the process for how NetLock validates the domain information, from the moment a customer makes a request to when it's issued?
  - Understanding how the information flows through your system is an important part to understanding how this issue came to be, and what appropriate mitigations are in place
- You indicated you added code to verify invalid characters. Could you explain more about what validation you added, specifically, to ensure that this validation does not suffer the same logic flaws seen at other CAs?
Flags: needinfo?(varga.viktor)
(In reply to Ryan Sleevi from comment #8)
> (In reply to Varga Viktor from comment #1)
> > > 5) Explanation about how and why the mistakes were made, and not caught and
> > > fixed earlier.
> > 
> > The main causes to not caught earlier:
> > 1. There was no clue about the mistake. Until the Android Chrome 58 update
> > every browser worked fine with this error
> > 2. The low volume of IDN certificates caused, that they were not targeted by
> > the spot checks.
> > 
> > 
> > After we caught we fixed it ASAP, then we worked on the replacement of the
> > certificates together with the customers.
> 
> Thanks for responding. I think it's still necessary to provide additional
> detail.
> 
> That is, we can look at the problem from two dimensions: The problem itself,
> and the systemic issues that allowed the problem to manifest. Your
> description focuses on the resolution of the problem, but doesn't indicate
> any systemic changes have been made. As a consequence, it does not help the
> community feel that your CA has taken steps to reduce the risk of future
> violations (of any requirement) in the future. That is, one dimension is
> "Did you fix the bug", but another dimension is "How was the bug introduced,
> why was it not detected, and what steps are you taking to prevent future
> bugs"
> 
> To understand how you might approach this problem, consider
> https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/
> W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were
> already in place (and with substantial detail), where there were controls
> missing or mistakes made, details about the steps being taken (e.g. "We
> fixed the bug" is not sufficient detail to understand), and a holistic,
> systemic awareness of how the CA is managed and the opportunities for errors.

I will compile you the list in same form. Thank you for pointing an example.

> In this particular case:
> - As you noted, you failed to detect this issue until a customer reported a
> compatibility issue. Yet none of your remediation plans include steps to
> improve detection tooling. Why is that?

We didn't choose the software/component to integrate/interface to our system.

> - The failure to reply in a timely fashion was due to human factors. Yet it
> sounds like your proposed remediation is to still rely on human factors (to
> escalate the issue). Did you consider any technical solutions to ensure
> proper monitoring and alerting for problem reports?

Yes, of-course, but we didn't find good solution for the process of free text emails.
The revocation email is separated to a different queue, with higher priority, but to understand the email 
we still needs human checking.

> - You indicated that 'another type verification is needed because the
> different character set size of the CN and the SAN in the case of IDNs'. I'm
> not sure that I fully understand what you're trying to say.

I used wrong word. Sorry. Corrected:
"... because the different character set TYPE of the CN and the SAN in the case of IDNs."

In the CN encoded in UTF8, but the SAN in dnsName.
To protect ourselves from homograph attacks, back in time filter was implemented, the to accept only hungarian characters.
(Because in the case of digital signature certificates the CN includes hungarian names.)
We implemented more filtering now on SSL certificates.


If you check the other CAs on the missued.com, you will find out, there is two kind of errors listed can be found connected to IDNs.
  
1. CAs operating in Hungary - accented chars in SAN
We are falling in this category.
I think this came from small misunderstood of the hungarian domain registration rules, which causes
that all of the affected certificates issued by hungarian CAs included in the SAN both the punycoded and the UTF8 encoded version of those accented domain names. (its only 3 different domains)

2. CAs operating outside Hungary - accented chars in the CN only, converted into nice punycode as SAN entry.
In this case the certificate successfully validated against the ASN.1 encoding rules, but fails from the view BR. 

> Can you please
> describe the process for how NetLock validates the domain information, from
> the moment a customer makes a request to when it's issued?
>   - Understanding how the information flows through your system is an
> important part to understanding how this issue came to be, and what
> appropriate mitigations are in place

I will compile you the list.

> - You indicated you added code to verify invalid characters. Could you
> explain more about what validation you added, specifically, to ensure that
> this validation does not suffer the same logic flaws seen at other CAs?

There are a few automatic tests, before the ownership of the domain name is checked.
-the public key included in the pkcs#10 requests checked against the Debian weak key list (its ok, when not on list
-key size check (its ok when 2048 or higher RSA)
all the domain names included in the request undergo the following steps:
-CAA record check (its ok to issue when Netlock is identified, or no CAA record)
-public suffix list validation check (its ok, when no exact match)
-Microsoft filter list check (Microsoft sent a list previously filter those domains out, its ok, when no exact match)
-High risk list check (we compiled list with low probability but high risk by ourselves, to filter them out, its ok, when no exact or partialy match, so maind domain and also subdomain are filtered). 
(For example we filter the google domains out, because we don't see the possibility of it.)
-domain syntax check
The latest check was added after the detection of the error:
-domain charset check (its ok, when only dnsName charset is used)

Sincerely yours, 
Viktor Varga
Flags: needinfo?(varga.viktor)
Dear Ryan,

The timeline is the following:

2017.07.05 - The owner of the domain partner.biztositas.hu reported us technical problem on Chrome 58 Android version. Netlock started to investigate the case. We found out that the problem came from dnsName encoding problem and affects IDNS so the IDN certificates issuance was suspended, until we found of cause. 2017.07.06 - We filtered trough our database for affected certificates and found the another accented domain misissued (webkonnyen.hu)
2017.07.07 - We contacted both of our customers to replace those certificates
2017.07.08 - We educated our collegues about the speciality of the IDNs and the new handling rules. IDN issuance is allowed again, but there was no request.  
2017.07.20 - The invalid charset check went into release, together with other implemented checks
2017.08.08 - Jonathan Rudenberg sent us a mail, but the replacement process of these certificates were already started.
2017.08.16 - Netlock got Mozilla bug ticket
2017.08.17 - Customers reported back the replacement of the certificates, the affected certificates were revoked.
2017.08.18 - We replied the mail to Jonathan
2017.08.18 - We reported the case to the MS too
2017.08.22 - MS case closed

New measures:
1. We set up a char encoding check on the SAN fields to block out the accented chars from it. It's already set now.
2. We are planning to integrate the Certlint into the issuance process.

Yours, Viktor Varga
Netlock
Thank you for that level of detail in the timeline. This is a good example of a disclosure that helps understand what the CA did and did not do.

Can you confirm the summary of this issue:

1) Invalid DNS names (U-labels instead of A-labels)
  - See Comment #0, Comment #1, Comment #7, Comment #9, Comment #10
  - Remediation:
    - 2017-07-20 - Filter for U-label DNS names implemented

Is that a correct summary?

Open Questions:
- Are you saying your system appropriately validated the IDN domains (e.g. webkönnyen.eu aka xn--webknnyen-37a.eu ), but simply did not encode them properly in the subjectAltName? At what point does your system convert to A-Label (from U-Label) and back. The concern here is that, notwithstanding the U-label, if the system was properly enforcing RFC1034 syntax (your noted pre-existing "domain syntax check"), such U-labels would never have passed. So it does not seem sufficient to just filter for U-labels, but to ensure the proper domain construction is followed.
Flags: needinfo?(varga.viktor)
(In reply to Ryan Sleevi from comment #11)
> Thank you for that level of detail in the timeline. This is a good example
> of a disclosure that helps understand what the CA did and did not do.
> 
> Can you confirm the summary of this issue:
> 
> 1) Invalid DNS names (U-labels instead of A-labels)
>   - See Comment #0, Comment #1, Comment #7, Comment #9, Comment #10
>   - Remediation:
>     - 2017-07-20 - Filter for U-label DNS names implemented
> 
> Is that a correct summary?

Yes.

> Open Questions:
> - Are you saying your system appropriately validated the IDN domains (e.g.
> webkönnyen.eu aka xn--webknnyen-37a.eu ), but simply did not encode them
> properly in the subjectAltName? At what point does your system convert to
> A-Label (from U-Label) and back. 

There was no conversion between the A-label and U-label.
In these accented domain cases bot the affected certificates also were wildcard certificates, so both of them are validated as OV, following the BRG 1.4.1 Section 3.2.2.1 and 3.2.5.

Because the Registrar reported back the domain valid, and it was owned by the Applicants legal identity, so  the domain name was added to the certificate as Ok then later after all other OV checks they were issued.

> The concern here is that, notwithstanding
> the U-label, if the system was properly enforcing RFC1034 syntax (your noted
> pre-existing "domain syntax check"), such U-labels would never have passed.
> So it does not seem sufficient to just filter for U-labels, but to ensure
> the proper domain construction is followed.

That domain syntax check was not implemented correctly before, but unfortunately the characters allowed the hungarian characters. Now its corrected, its not possible to add a SAN entry with wrong code page, only the dnsName set allowed.
Of-course its still possible to request an IDN certificate, but it should contain only dnsName set and punycode.
On the IDN domains we have implemented of-course some checks: still only hungarian chars allowed, in the tld section only the http://data.iana.org/TLD/tlds-alpha-by-domain.txt entries allowed.

Yours, Viktor Varga
Flags: needinfo?(varga.viktor)
(In reply to Varga Viktor from comment #12)
> > Open Questions:
> > - Are you saying your system appropriately validated the IDN domains (e.g.
> > webkönnyen.eu aka xn--webknnyen-37a.eu ), but simply did not encode them
> > properly in the subjectAltName? At what point does your system convert to
> > A-Label (from U-Label) and back. 
> 
> There was no conversion between the A-label and U-label.
> In these accented domain cases bot the affected certificates also were
> wildcard certificates, so both of them are validated as OV, following the
> BRG 1.4.1 Section 3.2.2.1 and 3.2.5.
> 
> Because the Registrar reported back the domain valid, and it was owned by
> the Applicants legal identity, so  the domain name was added to the
> certificate as Ok then later after all other OV checks they were issued.

I'm still a little confused by this. 3.2.2.1 describes how to validate the organization, and 3.2.5 describes how the request is authenticated, but that doesn't describe how you validated the domain (3.2.2.4). Could you explain what method you used to validate this domain, and how you validated it at the IDN/U-label form?
Flags: needinfo?(varga.viktor)
Dear Ryan, 

In the 3.2.2.4.1 there is three ways to validate the Domain names, and we used the first one in this case.

It says, 
"1. The	CA authenticates the Applicant's identity under	BR Section 3.2.2.1 and the authority	of	the Applicant Representative under BR Section 3.2.5, OR"
So these were checked against domain registrar data.
Because the registrar gives response on the U-label domain names too, the accented entries were accepted here, because the registrar give positive entry (however, the registrar response is missleading in the case of accented characters because it use the same head in the response for 
the unicode certificates and for the latin ones.
If a certificate request includes a punycode request, its checked against a punycode checker of-course.

Now, we changed this, and no entries other than dnsName allowed in the SAN in the cases of SSL certificates.

Yours, Viktor Varga
Flags: needinfo?(varga.viktor)
It appears that all actions have been completed and questions answered, so I am marking this resolved.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.