ICP-Brasil Root Inclusion Request
Kathleen Wilson
Brasil is the next request in the queue for public discussion.
ICP-Brasil (Brazil's national government CA) has applied to add the
“Autoridade Certificadora Raiz Brasileira” and “Autoridade
Certificadora Raiz Brasileira v1” root certificates and enable the
Websites trust bit.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=438825
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#ICP-Brasil
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=414133
Summary of Subordinate CA’s operated by third parties:
https://bugzilla.mozilla.org/attachment.cgi?id=391429
Noteworthy points:
* These root certificates are used to secure Brazilian government and
financial sites. The original root certificate is valid until
11/30/2011. The new root certificate (v1) is valid until 7/29/2021.
All of the sub-CAs of the original root will be migrated to the new
root.
* The CP and CPS documents are in Portuguese. English translations of
certain sections have been provided and verified using Google
Translate, and have been included in the Summary of Information
Gathered and Verified document.
** CP
http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-04_-_v._3.0.pdf
** CPS of CA-root
http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-01_-_versao_4.0_retificada_em_15-01-09.pdf
** CPS Requirements for sub-CA
http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-05_-_versao_3.1_(REQUISITOS_MIN._PARA_AS_DPCs_DAS_ACs).pdf
* The ITI (Instituto Nacional de Tecnologia da Informação), a Federal
organization linked to the Presidency of the Republic of Brazil,
operates the root certificates. The ITI authorizes, supervises and
audits the operations of 8 subordinate CAs that are externally
operated by other organizations.
** Diagram of the ICP-Brasil public key infrastructure
https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=342297
** Complete CA Hierarchy
http://www.iti.gov.br/twiki/pub/Certificacao/EstruturaIcp/Estrutura_completa.pdf
** High level description of each sub-CA:
http://www.iti.gov.br/twiki/bin/view/Certificacao/EstruturaIcp
* The request is to enable the Websites trust bit.
** CPS Requirements for sub-CA section 3.1.11 requires that the CPS
documents of the sub-CAs include the following in section 3.1.11.2:
For certified equipment or application using the URL field Common Name
must be verified if the applicant holds the certificate of
registration of domain name with the competent body, or has permission
from the owner field to use that name. In this case must be presented
documentation (term of authorization for use of domain or similar)
signed by the holder of the domain.
For example: consult WHOIS service
** CPS documents of the sub-CAs:
*** AC-Caixa: https://icp.caixa.gov.br/repositorio/DPCACCAIXAPF.pdf
*** AC-Serpro: https://ccd.serpro.gov.br/serproacf/docs/dpcserproacf_v2.0.pdf
*** AC-SERASA: http://publicacao.certificadodigital.com.br/repositorio/dpc/declaracao-scd.pdf
*** AC-Certisign:
http://icp-brasil.certisign.com.br/repositorio/dpc/AC_Certisign_Multipla/DPC_AC_Certisign_Multipla_v3.0.pdf
*** AC-SRF: http://www.receita.fazenda.gov.br/acsrf/dpcacsrf.pdf
(note: the domain verification procedures are in the CPS documents of
the sub-CAs of this sub-CA, links are in the Summary of Sub-CA’s
document listed above.)
*** AC-PR: https://ccd.serpro.gov.br/ACPR/docs/dpcacpr.pdf
*** AC-Jus (AC-CAIXA-Jus): https://icp.caixa.gov.br/repositorio/DPCACCAIXAJUS.pdf
*** AC-Imprensa-Oficial-Estado-SãoPaulo:
http://www.imprensaoficial.com.br/PortalIO/Certificacao/downloads/pdf/RFB/DPC_AC_IMESP_RFB_v3.0.pdf
* Test Websites
** Old Root: https://internetbanking.caixa.gov.br/SIIBC/index.processa
** New Root: https://ccd.serpro.gov.br/certificados/index.htm
*** The website for the old root loads the sub-CAs automatically.
*** The SSL cert of the test website for the new root uses the AIA
extension to specify the CA Issuers URI, so the webserver doesn’t auto-
load the sub-CAs. Firefox does not currently support this use of AIA,
as per bugzilla #399324. In order to see the full chain, I also had to
manually install these subCAs:
https://ccd.serpro.gov.br/acserpro/docs/serprov2.crt
https://ccd.serpro.gov.br/acserpro/docs/serprofinalv2.crt
* CRL: CPS Requirements for sub-CA section 4.4.9.2: The maximum
frequency allowed for the issuance of CRL for the certificates of end
users is 6 hours.
* OCSP: There is no OCSP support at the root level. If a sub-CA
supports OCSP, then their CPS must state so in section 4.4.11. It does
not appear that any of the sub-CAs currently provide an OCSP service
under this root.
* Audit: ITI has an audit committee that has been performing annual
audits against the Brazilian standards, which are equivalent to ETSI
TS 101 456 and ETSI TS 102 042. ITI also audits the sub-CAs annually.
The second-level sub-CAs and the RAs are either audited by ITI or by
an independent auditor accredited by ITI. The audit reports are
currently confidential. ICP-Brasil is budgeted to have an independent
audit performed in 2010. The sub-CAs are also working on independent
audits, which will be available in 2010. ICP-Brasil has requested that
we move forward with processing this request, with the understanding
that the audits are forthcoming.
This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may
be needed as follow-up.
Kathleen
Kathleen Wilson
ICP-Brasil?
I realize it's a big one to review, and I will greatly appreciate your
effort and input.
If you are new to reviewing root inclusion requests, you can find
information about what to look for here:
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Note: Extending the discussion period for this request for another
week.
Kathleen
Eddy Nigg
Thanks. I haven't come around to look at it yet - actually I forgot
there is an active review.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Ian G
> * These root certificates are used to secure Brazilian government and
> financial sites.
1. What does "financial" mean in this context?
2. Can we confirm that all certificates are issued within the Brazilian
government?
> * The ITI (Instituto Nacional de Tecnologia da Informa��o), a Federal
> organization linked to the Presidency of the Republic of Brazil,
> operates the root certificates. The ITI authorizes, supervises and
> audits the operations of 8 subordinate CAs that are externally
> operated by other organizations.
> ** Diagram of the ICP-Brasil public key infrastructure
> https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=342297
> ** Complete CA Hierarchy
> http://www.iti.gov.br/twiki/pub/Certificacao/EstruturaIcp/Estrutura_completa.pdf
> ** High level description of each sub-CA:
> http://www.iti.gov.br/twiki/bin/view/Certificacao/EstruturaIcp
8 Sub CAs. As far as I can see, Certisign and Caixa are commercial
companies ... so let's narrow this down:
Are some of the sub CAs non-governmental?
> * OCSP: There is no OCSP support at the root level. If a sub-CA
> supports OCSP, then their CPS must state so in section 4.4.11. It does
> not appear that any of the sub-CAs currently provide an OCSP service
> under this root.
OK, can we request a statement on their plans on this? (I'm only asking
to speed up the inevitable request.)
> * Audit: ITI has an audit committee that has been performing annual
> audits against the Brazilian standards, which are equivalent to ETSI
> TS 101 456 and ETSI TS 102 042. ITI also audits the sub-CAs annually.
> The second-level sub-CAs and the RAs are either audited by ITI or by
> an independent auditor accredited by ITI.
OK, so all second-level sub-CAs are audited. I note that there is some
suggestion here that the audits may not be fully independent. But I
don't see a need to raise a flag on that one.
> The audit reports are
> currently confidential.
This however is more of an issue.
Do we know why this is?
What does confidential mean? To whom? If I get into a dispute with one
of the CAs, can I see the audit report?
> ICP-Brasil is budgeted to have an independent
> audit performed in 2010. The sub-CAs are also working on independent
> audits, which will be available in 2010. ICP-Brasil has requested that
> we move forward with processing this request, with the understanding
> that the audits are forthcoming.
OK. My view only, and no doubt others have other views:
I think I would be favourable on this if all certs and sub-CAs are
within the government sphere (according to some definition).
I think I would be favourable on this if we could identify who takes the
responsibility for a flaw, a breach or a badly issued cert. If for
example there were a clear breach of a cert, is it entirely clear who
pays the money for any losses?
But the notion of a public-facing CA which is selling certs to the
public, with confidential audits ... would be a surprise to me.
While I think the result might be fairer on the users (because the CAs
concerned will be forced to deliver credibility in other ways) and the
innovation is worth exploring ... I'm not sure Mozilla is ready for that?
iang
David E. Ross
>
> * Audit: ITI has an audit committee that has been performing annual
> audits against the Brazilian standards, which are equivalent to ETSI
> TS 101 456 and ETSI TS 102 042. ITI also audits the sub-CAs annually.
This means that the certificate authority audits itself. That should be
totally unacceptable.
I realize that some CAs that are government agencies are sometimes
audited by other government agencies. That is quite different from an
agency being audited by an organization within the same agency. I have
seen first-hand the results of the latter, and those results are quite
ugly.
> The second-level sub-CAs and the RAs are either audited by ITI or by
> an independent auditor accredited by ITI. The audit reports are
> currently confidential. ICP-Brasil is budgeted to have an independent
> audit performed in 2010. The sub-CAs are also working on independent
> audits, which will be available in 2010. ICP-Brasil has requested that
> we move forward with processing this request, with the understanding
> that the audits are forthcoming.
Confidential audit reports are also unacceptable.
This request should be removed from the queue until the outside audit
report is made available.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Eddy Nigg
> Confidential audit reports are also unacceptable.
>
> This request should be removed from the queue until the outside audit
> report is made available.
>
I agree on both points with David, specially the later. Concerning the
former point I'd have probably to add something, but I prefer not to
invest a lot of time into this request if the audit reports are not public.
Kathleen, could you clarify this point and if that's correct, why has
the CA been admitted for public discussion?
Eddy Nigg
>
> This request should be removed from the queue until the outside audit
> report is made available.
>
I agree on both points with David, specially the later. Concerning the
Ian G
> On 12/03/2009 06:51 AM, David E. Ross:
>> This request should be removed from the queue until the outside audit
>> report is made available.
>
> .... Concerning the
> former point I'd have probably to add something, but I prefer not to
> invest a lot of time into this request if the audit reports are not public.
>
> Kathleen, could you clarify this point and if that's correct, why has
> the CA been admitted for public discussion?
Thinking about this, the single attempt to get through the process is
quite brutal (and a few have commented that it is harder than
Microsoft). So it makes sense from a CA's pov that they try now, and
get some indication, understanding, familiarity ... before a later review.
Which underscores the asymmetry of the arrangement. So far we only have
a small almost-not quorum of people analysing, and a large mass of CAs.
The benefit accrues to the CAs, the work falls on others.
So your rejection of investment is probably a rational response to that.
Question is, what to do about it? I'm not referring to ICP-Brazil but
the next 100 requests.
How about ... you need 3 review-points to get through the process. And
you earn review-points by ... doing reviews?
iang
Eddy Nigg
On 12/03/2009 01:43 PM, Ian G:
>
> Thinking about this, the single attempt to get through the process is
> quite brutal (and a few have commented that it is harder than
> Microsoft). So it makes sense from a CA's pov that they try now, and
> get some indication, understanding, familiarity ... before a later
> review.
This obviously doubles our work sometimes, preferable the process is
completed with action items instead.
>
> Which underscores the asymmetry of the arrangement. So far we only
> have a small almost-not quorum of people analysing, and a large mass
> of CAs. The benefit accrues to the CAs, the work falls on others.
>
> So your rejection of investment is probably a rational response to
> that. Question is, what to do about it? I'm not referring to
> ICP-Brazil but the next 100 requests.
I think there are (and should be) basic conditions which have to be
complied before starting the public discussion. We know already that if
there are no public audit statements, that the request will be most
likely opposed. We know that if the CP/CPS isn't available in English
that it might delay the inclusion, we know that if the most important
bits aren't translated and preferable attested, there will be opposition.
In that respect I expect that some pre-filtering is done by Kathleen. I
suspect that she's done that, for some reason she decided nevertheless
to proceed. I'm interested to know what those considerations were at
this point.
Ian G
> I think there are (and should be) basic conditions which have to be
> complied before starting the public discussion. We know already that if
> there are no public audit statements, that the request will be most
> likely opposed. We know that if the CP/CPS isn't available in English
> that it might delay the inclusion, we know that if the most important
> bits aren't translated and preferable attested, there will be opposition.
>
> In that respect I expect that some pre-filtering is done by Kathleen. I
> suspect that she's done that, for some reason she decided nevertheless
> to proceed. I'm interested to know what those considerations were at
> this point.
Well, in the spirit of not blaming the messenger, I assume there is a
good reason, and that's always going to exist, one way or another. In
normal business there is always pressure to bypass the system.
Maybe we could be collecting the information as to common blockages. It
seems that a pattern is developing:
* non-english CPS
* non-published audit reports
* domain ping checking not fully explained in CPS
according to Mozilla prescription
Any others? Perhaps it's time to start recording a "top ten" list of
reasons why there are problems with reviews?
iang
Eddy Nigg
> Well, in the spirit of not blaming the messenger, I assume there is a
> good reason, and that's always going to exist, one way or another. In
> normal business there is always pressure to bypass the system.
>
> Maybe we could be collecting the information as to common blockages.
> It seems that a pattern is developing:
>
> * non-english CPS
> * non-published audit reports
> * domain ping checking not fully explained in CPS
> according to Mozilla prescription
>
> Any others? Perhaps it's time to start recording a "top ten" list of
> reasons why there are problems with reviews?
>
I think that's too easy. But basically if you look at the
https://wiki.mozilla.org/CA:How_to_apply you'll see that most is
covered, either at https://wiki.mozilla.org/CA:Recommended_Practices or
at https://wiki.mozilla.org/CA:Problematic_Practices or the Mozilla CA
policy itself.
I think that we shouldn't introduce yet another rule, document or process.
Ben Wilson
qualified to do the kinds of reviews you're talking about? I assume the
reviewer has to be a third party neutral. What are the pre-requisites for
me, for instance, to be considered qualified? Do I have to go through some
application, vetting, approval and/or membership process?
--
Regards
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Eddy Nigg
> I'm new to this list, so I was wondering, how does Mozilla determine who is
> qualified to do the kinds of reviews you're talking about? I assume the
> reviewer has to be a third party neutral. What are the pre-requisites for
> me, for instance, to be considered qualified? Do I have to go through some
> application, vetting, approval and/or membership process?
>
Nothing of the like. I believe that you would be a good fit ;-)
But there are no requirements as far as I can tell. If you know about
CAs and PKI I believe any contribution is valued.
Ian G
> I'm new to this list, so I was wondering, how does Mozilla determine who is
> qualified to do the kinds of reviews you're talking about?
Anyone. Actually, the way it is written is that a public consultation
process will be followed. However the decision remains with Mozilla
Foundation, they can choose to ignore any recommendations in this forum.
Some time after it started, there was an evolved guideline that 2 people
comment. The basis of this is just that this shows public consultation
was done, not that it was done well.
> I assume the
> reviewer has to be a third party neutral.
You may assume that, but I would not ;-) I think it is par for the
course that no reviewer is neutral. We all have our biases. And,
especially, the only people really interested in it are CAs, the most
prolific or reviewers come from CA, so one can question our every
comment as biased.
> What are the pre-requisites for
> me, for instance, to be considered qualified?
You need to be able to read the documents that Kathleen assembles, and
comment. Hence, reading skills, a browser & PDF reader, typing skills
and a mail client is about all that is needed.
It helps immensely if you can inform your comments as: opinions,
questions, concerns and uncertainties, grounded in theories or
practices. That allows others who don't come from the same background
to work your viewpoints and tease out the nuances. Steer clear of
dogma, religion, bluster, RTFM, it adds little, we've seen it all
before. Feel free to play the devil's advocate, challenge everything.
Come up with alternates, challenge the status quo, everything's
acceptable in the name of the end-user.
But all that is optional, it's not required ;)
> Do I have to go through some
> application, vetting, approval and/or membership process?
You did it already by sending this email :)
Welcome! I've actually been very busy at the CA, they gave me a new
job, and it's drained my time & energy. So more reviewers are very welcome.
iang
Varga Viktor
If a domain was delegated, what is the level of the verification of the delegator?
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Eddy Nigg
> Sent: Thursday, December 03, 2009 11:35 AM
> To: dev-secur...@lists.mozilla.org
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> _______________________________________________________________________
> _
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Kathleen Wilson
> suspect that she's done that, for some reason she decided nevertheless
> to proceed. I'm interested to know what those considerations were at
> this point.
ICP-Brasil and their sub-CAs have been getting audited regularly, but
they need to update their audit procedures in order to fully meet the
requirements of the Mozilla CA Policy. ICP-Brasil is aware that their
request for root inclusion cannot be approved until they have
completed their upcoming audits.
However, ICP-Brasil specifically asked that we proceed with the rest
of the process, so that they would have time to resolve any concerns/
issues raised during public discussion before the upcoming audit.
The alternative is to make them wait until their upcoming audit is
performed, and then possibly find out during public discussion that
there is something that they need to change and get re-audited. Then
they could potentially end up having to go through all of the audits
for the root and all the sub-CAs again, and then go through the second
round of discussion.
As you've stated, the problem with moving forward with the discussion
now, is that we are guaranteed to have to do two rounds of
discussion. However, when I start the second round of discussion, I
will summarize the results from the first round, in an effort to not
have to re-discuss everything again. Just like what we do for other
CAs who end up having to go through two rounds of discussion.
This particular CA has been very pro-active in providing their
information. They got into the queue for public discussion and waited,
just like very other CA. However, they did it early enough so that if
there are changes they need to make, they can do so before their next
audit.
Given the complexity of this particular root and sub-CAs, I propose
that we continue with this discussion in order to ferret out all of
the concerns, and give the CA time to respond to the concerns and be
able to demonstrate that they have done so in their upcoming audit.
Kathleen
Kathleen Wilson
> you earn review-points by ... doing reviews?
That's an interesting concept. Given that CAs have to wait in the
queue for public discussion, they could potentially help speed up the
queue by contributing to the discussions ahead of theirs. This would
also give them good visibility into what to expect during their own
discussion.
If there aren't huge objections to this, I'll think about it some more
and figure out how to track/enforce it, then I'll open a separate
discussion with my proposal.
Kathleen
Frank Hecker
> I'm new to this list, so I was wondering, how does Mozilla determine who is
> qualified to do the kinds of reviews you're talking about? I assume the
> reviewer has to be a third party neutral. What are the pre-requisites for
> me, for instance, to be considered qualified? Do I have to go through some
> application, vetting, approval and/or membership process?
See the prior responses from Ian and Eddy. To add those:
If you are interested in how CAs work and want to help with Mozilla's
evaluation of CAs then you are welcome to comment. If you don't know a
lot about how CAs work then this is probably one of the better places in
the world to learn about how things are really done in practice (as
opposed to in theory).
If you see something about a CA that looks strange then please feel free
to comment on it; don't worry about it being a "stupid question". There
have been numerous occasions in the CA/PKI world where the "conventional
wisdom" turned out to be not so wise after all.
If you haven't read it already, probably the best place to start is the
"how to apply" document
https://wiki.mozilla.org/CA:How_to_apply
It's directed at CAs but is also useful as an overview for what Mozilla
is looking for from CAs.
Finally, note that while everyone's free to comment on CAs, only two
people are authorized to speak for Mozilla when it comes to CA-related
decisions, Kathleen Wilson and myself. And I defer to Kathleen's
recommendations unless there's a really compelling reason to do
otherwise, so in practice it's Kathleen who'll have the final word on
any given issue.
Thanks a lot for your interest in the Mozilla CA process. I hope you'll
have the time and inclination to participate in these discussions.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> Thanks a lot for your interest in the Mozilla CA process. I hope you'll
> have the time and inclination to participate in these discussions.
One other thing: I only noticed after sending my message that you work
for Digicert (so presumably you do know something about CAs :-). As Ian
noted, this is a public group on which anyone can comment; this includes
people from one CA commenting about other CAs with which they compete. I
personally have no objection to that practice, as long as people make
their affiliation known and keep a civil tone to their comments.
Opinions that are apparently motivated primarily by competitive animus
will be discounted accordingly.
Kyle Hamilton
<hec...@mozillafoundation.org> wrote:
> Frank Hecker wrote:
>
> One other thing: I only noticed after sending my message that you work for
> Digicert (so presumably you do know something about CAs :-). As Ian noted,
> this is a public group on which anyone can comment; this includes people
> from one CA commenting about other CAs with which they compete. I personally
> have no objection to that practice, as long as people make their affiliation
> known and keep a civil tone to their comments. Opinions that are apparently
> motivated primarily by competitive animus will be discounted accordingly.
>
> Frank
I'd like to add:
Eddy Nigg, of StartCom (startssl.com), was the one who identified the
lack of domain checking in certificates being issued by Comodo. He
was... attacked, rather bitterly, by virtue of his being employed by
(and running) a different CA. However, such attacks never (at least
to my sight) came from the Mozilla Foundation or even from anyone
working on NSS. (Certainly not Frank, nor Kathleen.)
Pragmatically, only those who understand what CAs actually certify can
really provide much in the way of comment on CPSes. Those who have
had to work with maintaining secure servers on the public network can
provide a lot more comment on what they need that CAs aren't
providing. (Such as "written contracts for relying parties for SOX
compliance.")
If you understand the difference between 'domain validation',
'original validation', and 'extended validation', my opinion is that
you qualify, and we are very glad to have you. :) If you have
suggestions on better ways to perform domain control checking -- or
anything else that's in the CPSes we evaluate -- please speak up.
I do have a question for Ben: In what capacity are you representing
Digicert, if at all? Please understand, it is perfectly okay to have
an "I am responsible for my own opinions, Digicert does not have
opinions on what I have opinions on" disclaimer. It's also perfectly
okay to have an "I am a technical evangelist for Digicert" hat, or an
"I am completely confused how any of these CAs got in here" hat, or
any other hat. Frank doesn't mind having representatives of other CAs
discussing current applications, and there have been at least two
items that were first discussed/disclosed here that were then taken to
the CA/B Forum.
(Johnathan Nightingale, Mozilla/NSS's "Human Shield", is Mozilla's
delegate to the CA/B Forum. Are you involved in that capacity for
Digicert?)
-Kyle H
Ian G
> He
> was... attacked, rather bitterly, by virtue of his being employed by
> (and running) a different CA.
Well. If we're going to fight old wars like veterans over cups, recall
that there are others here who have different memories.
Specifically, there is no carte blanche granted to one CA to attack
another here, for any excuse, and there is no denying others the right
of a fair hearing over some flaw or other.
> However, such attacks never (at least
> to my sight) came from the Mozilla Foundation or even from anyone
> working on NSS. (Certainly not Frank, nor Kathleen.)
2 points: Mozilla are the ones responsible. And they have to deal the
cards in the next round. So they can't really afford to get stuck in
the debate, and definately not if it leads to charges of favouritism.
Also, the episide you mention was during the vacations period. This had
a non-trivial effect on Mozilla's capability to deal.
iang
Ben Wilson
Thanks for your suggestions--I'm sure I'll use a few of them when I post to
this list. However, I've got to run out the door now, so the short answer
is that I am a member of the list in my capacity with DigiCert. I could
provide more explanation on the list--and will try later--but I have to
leave now.
Thanks again,
Ben
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Kyle Hamilton
Sent: Thursday, December 03, 2009 4:01 PM
To: Frank Hecker
Cc: dev-secur...@lists.mozilla.org
Subject: Re: how to get more review?
On Thu, Dec 3, 2009 at 1:16 PM, Frank Hecker
<hec...@mozillafoundation.org> wrote:
> Frank Hecker wrote:
>
> One other thing: I only noticed after sending my message that you work for
> Digicert (so presumably you do know something about CAs :-). As Ian noted,
> this is a public group on which anyone can comment; this includes people
> from one CA commenting about other CAs with which they compete. I
personally
> have no objection to that practice, as long as people make their
affiliation
> known and keep a civil tone to their comments. Opinions that are
apparently
> motivated primarily by competitive animus will be discounted accordingly.
>
> Frank
I'd like to add:
Eddy Nigg, of StartCom (startssl.com), was the one who identified the
lack of domain checking in certificates being issued by Comodo. He
was... attacked, rather bitterly, by virtue of his being employed by
(and running) a different CA. However, such attacks never (at least
to my sight) came from the Mozilla Foundation or even from anyone
working on NSS. (Certainly not Frank, nor Kathleen.)
Pragmatically, only those who understand what CAs actually certify can
-Kyle H
Ruy Ramos
> The domain delegation field int he information gathering is empty.
>
> If a domain was delegated, what is the level of the verification of the delegator?
>
> Üdvözlettel/Regards,
>
> Varga Viktor
> IT Service and Customers Service Executive
> Netlock Kft.
>
Not applicable within CA-root of ICP-Brasil. For sub-CAs, see 438825-
subCA-review.pdf.
Ruy Ramos
ITI/Brazil
Kyle Hamilton
> On 04/12/2009 00:01, Kyle Hamilton wrote:
>>
>> was... attacked, rather bitterly, by virtue of his being employed by
>> (and running) a different CA.
>
>
> there are others here who have different memories.
>
> Specifically, there is no carte blanche granted to one CA to attack another
> here, for any excuse, and there is no denying others the right of a fair
> hearing over some flaw or other.
Right. I also admit that my response was perhaps a bit
over-the-top... but having a reseller issue a certificate for the
domain mozilla.org to someone who obviously didn't have control over
it was something that needed to be brought to the table, and quickly.
I can't even really fault Eddy for being furious about it, as his own
CA's reputation (as well as ALL CA reputations) was being besmirched
by a competitor for something he wasn't responsible for.
My own animus was (and remains) that these people are supposed to
*check*, dammit.
I look at it this way: certifying authorities are essentially trying
to act like digital notaries. The CA in question, if viewed as a
notary, essentially allowed someone else to fill in its logbook, and
blindly rubber-stamped and signed (the two separate affirmative
actions that a notary must make before a notary's signature is
accepted as an attestation), a document essentially stating that the
controller of the mozilla.org domain asked it for presentable,
verifiable evidence that the webserver was, in fact, run by the
controller of mozilla.org, as attested by an uninterested, and thus
more inherently trustworthy, third party. (I'm reminded of the quote:
"A commercial CA protects you from anyone whose money it refuses to
take." -- attributed to Matt Blaze in an RSA2000 hallway discussion.)
>> However, such attacks never (at least
>> to my sight) came from the Mozilla Foundation or even from anyone
>> working on NSS. (Certainly not Frank, nor Kathleen.)
>
>
> 2 points: Mozilla are the ones responsible. And they have to deal the
> cards in the next round. So they can't really afford to get stuck in the
> debate, and definately not if it leads to charges of favouritism.
Mozilla (et al) are responsible for the final decision. The fact that
there is an arbitration (with Frank handing over the reins to Kathleen
while still making sure that if she makes some... very strange mistake
(which I would call 'strange' simply because she's been very excellent
at keeping track of things -- thanks again, Kathleen!)) means that the
arbiter *must* be neutral.
That the arbiter (Frank, I think, more than Kathleen -- though she did
play an essential part in figuring out just what happened) did stay
neutral during the temper-flaring speaks volumes about the quality of
leadership here -- and none of it negative.
> Also, the episide you mention was during the vacations period. This had a
> non-trivial effect on Mozilla's capability to deal.
Ah, the Silicon Valley Shutdown at the end of every year. I agree
with you, that it was during the vacations period... but I have to
wonder about the timing of the spam that led to the flaw's discovery,
if it was intentionally placed then specifically to confuse the
response. (I imagine I'll never find out.)
Normally there's someone left behind who can mind the store while the
chief's away... though usually, that's just the network engineering
and administration staff. Having a single vacation period where
everyone's away means that there's a week or two window of being able
to make major network infrastructure changes... but it also means that
there's less of an emergency response team available. (This suggests
that someone should be around to make emergency decisions until Frank
and/or Kathleen comes back. I'd rather do a temporary trust-removal
than a full root-removal, but I think that the lack of trust-removal
indicates a lack of emergency preparedness. What kinds of business
continuity plans does Mozilla have in the event that Kathleen and
Frank both die in an earthquake? How would their successors be
chosen?)
-Kyle H
Frank Hecker
> What kinds of business
> continuity plans does Mozilla have in the event that Kathleen and
> Frank both die in an earthquake?
Right now there are at least four people whom I consider to be in a
reasonable position to make decisions relating to CAs: Kathleen, myself
as backup to Kathleen, and Gervase Markham (of the Mozilla Foundation)
and Johnathan Nightingale (of the Mozilla Corporation) as further
backups. Gerv has done CA evaluation before and is familiar with the
issues. Johnath is our representative to the CAB Forum and also very
involved in discussions around security vulnerabilities.
> How would their successors be chosen?)
The Mozilla project has a reasonably formal process for appointing
people to positions of authority within the project. (Google for
"Mozilla module owners".) That's the process, for example, by which
Kathleen was appointed a peer to me for CA decisions. Any successors to
Kathleen or I would be chosen through a similar process.
Of course the process is irrelevant if there aren't people who have the
time and expertise to do the work. One of the nice things that's
happened over the past year or two is that the Mozilla organizations
(most notably the Mozilla Corporation) have realized that the CA work
was important enough that it's worth funding someone (namely Kathleen)
to do it on an ongoing basis. Presumably if Kathleen ever got tired of
doing the work (or couldn't do it) then MoCo would be willing to find
and fund someone else to take it over. Like Kathleen did, such a new
person would likely go through an initial period of working under
supervision prior to taking on formal authority if they were doing a
good job.
I should also add that technically you don't need to be a Mozilla
employee to have formal project authority; for example, I had formal
responsibility for doing the CA stuff back when I was a volunteer.
However in practice it would be hard for someone to do the work
full-time or nearly so if they weren't employed by Mozilla or someone
else to do it.
Eddy Nigg
> I can't even really fault Eddy for being furious about it, as his own
> CA's reputation (as well as ALL CA reputations) was being besmirched
> by a competitor for something he wasn't responsible for.
>
> My own animus was (and remains) that these people are supposed to
> *check*, dammit.
>
Well, actually there was at least also a surprise element in addition to
what you mentioned above. Specially since I was preaching for a higher
adoption of "trusted" SSL certificates and worked towards having better
signals in the browser - this incident (and some other incidents) really
took myself by surprise because I believed it can never happen in the
way it happened to me. I sincerely believed that domain control
validation and other important bits of the processes are never
outsourced to some coming along resellers or RAs (Why would a CA like to
do that and sign certificates blindly without any due diligence? How
come that some shared hosting account at a reseller can perform these
checks, as if it's a user forum or blog I'm subscribing to? And why
should other CAs have to go into great length to secure their
applications and infrastructures, if your neighbor just does it much
easier at the shared hosting account without all the hassles?)
> I look at it this way: certifying authorities are essentially trying
> to act like digital notaries. The CA in question, if viewed as a
> notary, essentially allowed someone else to fill in its logbook, and
> blindly rubber-stamped and signed (the two separate affirmative
> actions that a notary must make before a notary's signature is
> accepted as an attestation), a document essentially stating that the
> controller of the mozilla.org domain asked it for presentable,
> verifiable evidence that the webserver was, in fact, run by the
> controller of mozilla.org, as attested by an uninterested, and thus
> more inherently trustworthy, third party. (I'm reminded of the quote:
> "A commercial CA protects you from anyone whose money it refuses to
> take." -- attributed to Matt Blaze in an RSA2000 hallway discussion.)
>
This is really the reason why I believe that the regimes controlling CAs
must be tightened and improved - and incidentally this must be done over
the board and equally, before we can relax again. Unfortunately this
might also hurt those CAs a bit which aren't subject to problematic
practices, but it is required to have all CAs adhere to a minimal
standard in order to improve the overall quality. This is important in
order for us (Browser vendors and CAs alike) so that the users can trust
the decisions taken by the browser - mostly through the UI and this
forum. Otherwise we simply can skip it, pack our bags and forget about
SSL/TLS and live with a fact of no protection on the net.
I think this is pretty much what happened here in this forum actually.
The level has been raised and the regime enforces much better control
today than just two years ago. There are probably still some improvement
to be made, the handling of the latest incident surrounding the OCSP
services of a certain CA wasn't really top notch...but there are many
more eyes watching the processes today, which I believe is for the
overall good.
Kyle Hamilton
> On 12/03/2009 02:43 PM, Ian G:
>>
>> Well, in the spirit of not blaming the messenger, I assume there is a good
>> reason, and that's always going to exist, one way or another. In normal
>> business there is always pressure to bypass the system.
>>
>> Maybe we could be collecting the information as to common blockages. It
>> seems that a pattern is developing:
>>
>> * non-english CPS
>> * non-published audit reports
>> * domain ping checking not fully explained in CPS
>> according to Mozilla prescription
>>
>> Any others? Perhaps it's time to start recording a "top ten" list of
>> reasons why there are problems with reviews?
>>
>
> I think that's too easy. But basically if you look at the
> https://wiki.mozilla.org/CA:How_to_apply you'll see that most is covered,
> either at https://wiki.mozilla.org/CA:Recommended_Practices or at
> https://wiki.mozilla.org/CA:Problematic_Practices or the Mozilla CA policy
> itself.
>
> I think that we shouldn't introduce yet another rule, document or process.
I disagree. I'd like to have it documented in a single place what
action items have fallen to CAs that get through first-round review;
I'd also like to have a place where CAs can look for additional
non-normative information about things that have worked for approval
in the past and things which haven't.
Such a document/site/wiki would need to point out, possibly on every
page, that the Mozilla CA Policy is the final controlling document,
and that it is subject to change.
I *would*, however, like to eventually start moving the more egregious
Problematic Practices into Policy. I would also like to see Mozilla
grow a pair and actually *enforce* that policy, by removing the trust
bits from CAs that have had both their actions and audits questioned
until the concerns are resolved to Mozilla's satisfaction. (Of
course, this would require Mozilla to not be satisfied by anything
less than adherence to its policy.)
-Kyle H
Eddy Nigg
> I *would*, however, like to eventually start moving the more egregious
> Problematic Practices into Policy.
>
Will this ever happen?
Eddy Nigg
> The domain delegation field int he information gathering is empty.
> subCA-review.pdf.
>
I've started to dive into this mammoth request and probably the next few
questions might determine the approach for reviewing. Basically it must
be understood that if a root is enabled, anything beneath will be
enabled too and it matters a lot what the root's requirements are. Hence
any question regarding requirements must apply from the root onward.
Now, I'm trying to make some sense from all that information (great job,
Kathleen!) , but this diagram
http://www.iti.gov.br/twiki/pub/Certificacao/EstruturaIcp/Estrutura_completa.pdf
is rather frightening. What bothers me mostly from what I've seen so
far, is that every intermediate CA has its own policies tied to the
requirements of ICP
(http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-05_-_versao_3.1_%28REQUISITOS_MIN._PARA_AS_DPCs_DAS_ACs%29.pdf)
but have their own interpretations too. So for example I found
delegation of validations to third parties amongst other things, but
also the interpretation for domain validation and other attributes. It
has already been noted that the intermediate CA are audited basically by
itself, but it appears tot me that the audit of the root is also kind of
self-audit (ICP is the national root, ITI is the national auditor).
I believe it would be beneficial to slice this request into a few
different parts or areas (by root and sub CA perhaps) and maybe by
starting with the root itself, its requirements and then branch out to
the sub CAs. As such, ICP is taking maybe a risk due to the fact that if
problematic practices in one or more CAs are noticed, it probable will
result into action items which would have to be implemented and checked
for each and every CA chained to ICP and with it prevent the inclusion
of the root until all issues are solved. This might greatly delay the
inclusion or even prevent it (there are other super-CAs which were
affected by that).
Alternatively we could start with the each CA chained to the ICP root
and start approving them individually (preferred) and once all of them
are approved, look at a possible inclusion of this root in case all CAs
made it (with considering the fact that there could be more CAs chained
to that root in the future). I've noted in the past, that independent
CAs should apply directly for inclusion even if they are chained to a
different root. I would support including the CA roots or intermediate
CA certificates after approval for inclusion.
Kathleen, this request would take me way more than a week to review. Can
we work out a different approach as suggested above (either way would be
fine, the later would perhaps allow for inclusions of the individual CAs
faster, the former might be blocking the whole process eventually).
PS. Kathleen, do you have a translated version of
http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-05_-_versao_3.1_%28REQUISITOS_MIN._PARA_AS_DPCs_DAS_ACs%29.pdf
? Google translate stops to translate for me at about the 13th page. I
can't read Portuguese.
Eddy Nigg
> Kathleen, this request would take me way more than a week to review.
> Can we work out a different approach as suggested above (either way
> would be fine, the later would perhaps allow for inclusions of the
> individual CAs faster, the former might be blocking the whole process
> eventually).
After reading a bit more through
https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=414133 I
believe to know the possible answer already. As Ian (I think) noted
already, ICP/ITI is auditing itself, I believe that we can not accept an
auditor also as a CA root.
There are some countries in which a national CA, sub or cross signs CA
roots operating in their jurisdiction, but these subordinated CAs have
been treated usually individually. In my opinion, the ICP root can not
be included because it is also the auditing authority. With that I
suggest to schedule the inclusion process for each individual CA (most
information gathering has already been done) and probably accept ITI as
an acceptable auditor according to the Mozilla CA policy, treat the
requirements of ICP as binding for any of the CAs under its regime - but
still reviewing each CAs CP/CPS and require audit statements for each CA.
Ian G
> On 12/05/2009 04:45 AM, Kyle Hamilton:
>> I *would*, however, like to eventually start moving the more egregious
>> Problematic Practices into Policy.
>
> Will this ever happen?
Policies aren't the place to list egregious practices, really. There
should be (IMO) a simple reference to a list of practices currently
considered unreasonable. And a clause that says that Mozilla can choose
to do what it sees fit.
iang
Eddy Nigg
That's a good idea and I would support it.
Ian G
I think the issues that came up last Xmas are really important. But I
don't support using them to fight reputation wars, and I don't like
encouraging people to do that on this list. I think it would be far
better for us to talk in the abstract, e.g. CA Acme.com had a breach
because its reseller made a mistake (or whatever).
On 04/12/2009 20:02, Kyle Hamilton wrote:
> On Thu, Dec 3, 2009 at 3:25 PM, Ian G<ia...@iang.org> wrote:
>> Specifically, there is no carte blanche granted to one CA to attack another
>> here, for any excuse, and there is no denying others the right of a fair
>> hearing over some flaw or other.
>
> Right. I also admit that my response was perhaps a bit
> over-the-top... but having a reseller issue a certificate for the
> domain mozilla.org to someone who obviously didn't have control over
> it was something that needed to be brought to the table, and quickly.
Oh, but that was done, no doubt about that.
The problem then occurred that the opportunity to complain and complain
and complain was just too tempting.
> .... his own
> CA's reputation (as well as ALL CA reputations) was being besmirched
> by a competitor for something he wasn't responsible for.
My own personal opinion: the damage to that business's reputation was
pretty much all "own doing."
Some of us even tried to reduce the damage to the reputation, but did
not succeed. (I recall Paul H also mailing on this point.)
> My own animus was (and remains) that these people are supposed to
> *check*, dammit.
And others have other animuses (if there is a plural...).
Specifically, the existance of a breach is *not news*.
This is encoded in the standard audit use of the word "reasonable" which
admits that mistakes can happen, systems aren't perfect, etc, and the
essence of the business problem is to find a balance.
The question really is one of whether the checks to accomodate this were
efficacious, and applied. However, because we currently use audits to
examine this area, we're stuck. We can't see into the audit (that's its
job in a nutshell, to see into that which we can't).
So we have no business -- this forum has no mandate -- to engage in a
long, loud and damaging campaign over a breach of procedures. The
solution to that, if you want that mandate, is to open up the audit
process. (You might recall that one person said "yes, we'll do that if
everyone else does it.......")
In absence of that, we're stuck.
On the other side of the same coin, the secrecy of the audit process
leads us to the inevitable but wrong step of assuming that everything is
perfect. That which we can't see is always assumed to be far better
than it really is. Firefox's colour coding, padlock, etc are Bismark's
sausages.
But we know that security isn't a science (!?) that delivers perfection,
it's risk-based. How far do you want to go in this pursuit of perfect
security? What is it worth to you to have zero breaches?
If you want that, the old chinese curse will likely apply.
http://www.csoonline.com/article/print/509739
Be careful what you wish for...
> I look at it this way: certifying authorities are essentially trying
> to act like digital notaries.
This is a view. Nobody's going to challenge it until some money is on
the table. And then, as soon as money is on the table, I predict that
view won't be worth the money ;) CAs are nothing like digital notaries.
(Although, perhaps you mean Notary Publics? That's a closer fit, but
even then, they are nothing like that, they are more like garages that
also deliver car-safety certificates.)
> The CA in question, if viewed as a
> notary, essentially allowed someone else to fill in its logbook, and
> blindly rubber-stamped and signed (the two separate affirmative
> actions that a notary must make before a notary's signature is
> accepted as an attestation), a document essentially stating that the
> controller of the mozilla.org domain asked it for presentable,
> verifiable evidence that the webserver was, in fact, run by the
> controller of mozilla.org, as attested by an uninterested, and thus
> more inherently trustworthy, third party. (I'm reminded of the quote:
> "A commercial CA protects you from anyone whose money it refuses to
> take." -- attributed to Matt Blaze in an RSA2000 hallway discussion.)
And that's another view. Which the CAs will aggressively attack, and
lead you to believe that the "notary view" is better.
But, Matt Blaze probably had good reason to say that, and the fact that
it became a famous aphorism indicates that many people think it on target.
> ... The fact that
> there is an arbitration (with Frank handing over the reins to Kathleen
> while still making sure that if she makes some... very strange mistake
> (which I would call 'strange' simply because she's been very excellent
> at keeping track of things -- thanks again, Kathleen!)) means that the
> arbiter *must* be neutral.
I proposed Arbitration or a method akin to it a while back, indeed my
thoughts were directed from the Xmas incident, to try and reduce the
damage done in that event. Do you think Arbitration might be a good idea?
(I don't know what you mean by ... very strange mistake, I've not
noticed it myself.)
> ... What kinds of business
> continuity plans does Mozilla have in the event that Kathleen and
> Frank both die in an earthquake? How would their successors be
> chosen?)
lol... one of my thoughts while engaged in a recent project of some
relationship to this list [1] is that ... as an organisation that is
purporting to protect its end-users with audits over CAs, Mozilla
probably should be audited itself.
(And, an auditor would ask exactly the question you asked above ;)
iang
[1] which I do not routinely name because it is unprofessional to use
Mozilla's policy list to promote ones project.
Rafael Coninck Teigão
I work for the Justice Court of the State of Parana, in Brazil. We are currently deploying a large lot of personal certificates and we are also users of ICP-Brasil SSL/TLS certs. Therefore I have a huge interest in seeing the inclusion of this root to go through, for at this moment we had to resort using a non-ICP issued cert (we were receiving tons of calls from users complaining that their browsers would issue a warning about the certificate.)
With that said, I'd like to point out that I agree with the idea of including the intermediate CA certs into Mozilla products first, mainly for the following two reasons:
1) some (most?) sub-CAs are also chained to different roots, and are probably sharing the same (most likely audited) infrastructure between these different roots;
2) some sub-CAs are in the private sector and have a pecuniary interest in being able to sell certificates that are recognized by the major browsers... it might even be a requirement in some tender process.
Cheers,
Rafael Coninck Teigão.
<snip>
Alternatively we could start with the each CA chained to the ICP root and start approving them individually (preferred) and once all of them are approved, look at a possible inclusion of this root in case all CAs made it (with considering the fact that there could be more CAs chained to that root in the future). I've noted in the past, that independent CAs should apply directly for inclusion even if they are chained to a different root. I would support including the CA roots or intermediate CA certificates after approval for inclusion.
<snip>
Eddy Nigg
> Hello everyone,
>
> I work for the Justice Court of the State of Parana, in Brazil. We are
> currently deploying a large lot of personal certificates and we are
> also users of ICP-Brasil SSL/TLS certs. Therefore I have a huge
> interest in seeing the inclusion of this root to go through, for at
> this moment we had to resort using a non-ICP issued cert (we were
> receiving tons of calls from users complaining that their browsers
> would issue a warning about the certificate.)
>
> With that said, I'd like to point out that I agree with the idea of
> including the intermediate CA certs into Mozilla products first,
> mainly for the following two reasons:
> 1) some (most?) sub-CAs are also chained to different roots, and are
> probably sharing the same (most likely audited) infrastructure between
> these different roots;
> 2) some sub-CAs are in the private sector and have a pecuniary
> interest in being able to sell certificates that are recognized by the
>
Thank you Rafael, I believe this is valuable information for the process
here. When a decision is made, I believe that Mozilla will have to
contact each CA and engage them for the inclusion. Obviously I also
believe that we should schedule the reviews according to relevance and
importance of the respective CA.
Eddy Nigg
Ian, would it be possible to move the section "Other considerations when
updating the CA Certificate Policy" out of the Problematic Practices and
dedicate a different page for that? Perhaps something which should guide
us regarding a potential policy update. I think this doesn't belong to
that page, it's a bit out of place.
Ruy Ramos
> On 26/11/2009 01:51, Kathleen Wilson wrote:
>
> > * These root certificates are used to secure Brazilian government and
> > financial sites.
>
> 1. What does "financial" mean in this context?
>
> 2. Can we confirm that all certificates are issued within the Brazilian
> government?
I think there is a little bit confusion sometimes because any
incomplete translations on our part.
We will try to better clarify:
a) The ICP-Brazil is a national system of digital certification
defined in law (MP 2200-2 /2001). Known as Brazil's National PKI (ICP-
Brasil). Digital certificates by ICP-Brazil should / can be used by
any sector of the economy, not just government or financial
institutions
b) In this system there are several actors: Committee-manager of ICP-
Brazil, CA-Root, sub-CA, among others (RA, PSS). The Committee-manager
has several responsibilities among the main agree on standards for ICP-
Brazil and audit/review the CA-Root. All members are appointed
directly by the President of Brazil. The ITI is a Brazilian government
agency that operates the CA-root. The ITI has no vote in the Committee-
manager. The ITI has 2 boards: one to operate the Ca-root and one for
audit/check/supervise the sub-CA (1º and 2º level). ITI is not self-
audits . In 2010 there will be CA-root audit by an external company as
determined Committee-manager. The ITI ( government agency) is not
required under Brazilian law to undergo an external audit since it is
audited by other government agencies (TCU and CGU).
c) We can say that all the certificates in the chain ICP-Brazil are
ultimately guaranteed by the brazilian federal government. As the root-
CA is operated by ITI (government agency) any damage caused to third
parties must be repaired. This is the Federal Constitution (1988),
“Article 37. The government directly and indirectly from any of the
powers of the Federal, State, Federal District and municipalities will
follow the principles of lawfulness, impersonality, morality,
publicity and efficiency, and also to the following: § 6 -
Corporations Law public and private providers of public services are
liable for damages that their agents, as such, cause to third parties,
ensuring the right of recourse against the responsible in cases of
fraud or negligence.”
d) And so: MP 2200-2 (law), August, 24 2001 say:
“Art.10 – Are considered public or particular documents, for all the
legal purposes, the electronic documents treated by this law.
§1° The declarations within the documents in electronic means produced
with the use of certification process provided by ICP-Brasil are
presumed true regarding its signators, in the form of article 131 of
the law 3.071 01/01/1916 – Civil Code.”
>
> 8 Sub CAs. As far as I can see, Certisign and Caixa are commercial
> companies ... so let's narrow this down:
>
> Are some of the sub CAs non-governmental?
Caixa: bank (public bank)
SERASA: commercial
Certisign: commercial
AC-jus: Justice/judiciary
AC-RFB: Brazilian IRS Dept. (government)
AC-PR: Presidency of Brazil
AC-IMESP: São Paulo government agency
AC-SERPRO: TI company (public)
>
> > * OCSP: There is no OCSP support at the root level. If a sub-CA
> > supports OCSP, then their CPS must state so in section 4.4.11. It does
> > not appear that any of the sub-CAs currently provide an OCSP service
> > under this root.
>
> OK, can we request a statement on their plans on this? (I'm only asking
> to speed up the inevitable request.)
The OCSP should be adopted soon to attribute AIA. In the first half of
2010.
>
> > * Audit: ITI has an audit committee that has been performing annual
> > audits against the Brazilian standards, which are equivalent to ETSI
> > TS 101 456 and ETSI TS 102 042. ITI also audits the sub-CAs annually.
> > The second-level sub-CAs and the RAs are either audited by ITI or by
> > an independent auditor accredited by ITI.
>
> OK, so all second-level sub-CAs are audited. I note that there is some
> suggestion here that the audits may not be fully independent. But I
> don't see a need to raise a flag on that one.
>
> > The audit reports are
> > currently confidential.
>
> This however is more of an issue.
>
> Do we know why this is?
>
> What does confidential mean? To whom? If I get into a dispute with one
> of the CAs, can I see the audit report?
The audit reports of CA-root are sensitive when it comes to
advertising. However, any interested citizen may refer to any process
at the headquarters of ITI without any restrictions. In the case of
reports of sub-ca, ITI publishes in the Diary Official of Brazilian
reported that a certificate provides sub-CA has been audited and is
operating according to standards (CP/CPS).
>
> > ICP-Brasil is budgeted to have an independent
> > audit performed in 2010. The sub-CAs are also working on independent
> > audits, which will be available in 2010. ICP-Brasil has requested that
> > we move forward with processing this request, with the understanding
> > that the audits are forthcoming.
>
> OK. My view only, and no doubt others have other views:
The problem is that the ITI is an agency that depends on the federal
budget.
The audit which we refer to is only the CA-root. The remaining audits
in sub-CA happen without restrictions annualy.
> I think I would be favourable on this if all certs and sub-CAs are
> within the government sphere (according to some definition).
>
> I think I would be favourable on this if we could identify who takes the
> responsibility for a flaw, a breach or a badly issued cert. If for
> example there were a clear breach of a cert, is it entirely clear who
> pays the money for any losses?
>
The chain of responsibility starts in the sub-ca (2º level. 1º level)
and should reach the CA-root. Remember, if there are problems
characterized in the root certificate so the Brazilian government pays
for the damage. If fraud is found or any other problem that causes
some loss to the citizens, the Brazilian government can be held
responsible, ultimately.
The sub-CA is obliged to issue an insurance policy that guarantees the
repair of damage to users.
Kyle Hamilton
Is this the first CA that actually *accepts* liability, not only for
itself but also for the actions of its sub-roots?! i.e., an agent
only has legitimate access to the signing key of any CA in the
hierarchy when he is in the role of agent as such, and doesn't have
access when when he isn't... which means that in any action of fraud
or negligence committed by him -- say, to issue a personal certificate
in someone's name to someone who wasn't entitled to it, either through
willful malfeasance or through just not checking as thoroughly as
necessary -- is ultimately up to the government to be liable for the
fraud, beyond the extent of the liquidity of insurance provided by the
sub-CA itself?
Wow. *THAT'S* something that a digital signature law should include, folks.
-Kyle H
Kyle Hamilton
your comments specifically intrigues me.
My only question at this point is, why aren't you also requesting the
S/MIME bit?
(more comments inline)
-Kyle H
On Mon, Dec 7, 2009 at 8:41 AM, Ruy Ramos <ruyram...@gmail.com> wrote:
>> > * OCSP: There is no OCSP support at the root level. If a sub-CA
>> > supports OCSP, then their CPS must state so in section 4.4.11. It does
>> > not appear that any of the sub-CAs currently provide an OCSP service
>> > under this root.
>>
>> OK, can we request a statement on their plans on this? (I'm only asking
>> to speed up the inevitable request.)
>
> The OCSP should be adopted soon to attribute AIA. In the first half of
> 2010.
I hope you're following (and have followed) the OCSP-related mails on
the list. To whit: don't make it an https:// URL (this could lock
agents into a loop where they're trying to obtain the OCSP request of
the web certificate for the OCSP server), and allow the use of GET as
well as POST. (And if you think that your AIA is invalid in a GET
without the concept of a query string in CGI form, you can set your
AIA to something like "http://ocspserver.iti.br/cgi-bin/ocspquery?q=".
If q is empty, you know it's a POST, and if it's not, you know it's a
GET. Not that you wouldn't know by other means, but it's one way I
figured out where variables came from in older versions of PHP.)
>> > The audit reports are
>> > currently confidential.
>>
>> This however is more of an issue.
>>
>> Do we know why this is?
>>
>> What does confidential mean? To whom? If I get into a dispute with one
>> of the CAs, can I see the audit report?
>
> The audit reports of CA-root are sensitive when it comes to
> advertising. However, any interested citizen may refer to any process
> at the headquarters of ITI without any restrictions. In the case of
> reports of sub-ca, ITI publishes in the Diary Official of Brazilian
> reported that a certificate provides sub-CA has been audited and is
> operating according to standards (CP/CPS).
This is intriguing to me. "when it comes to advertising"? As in, who
is it illegal to disseminate the information to, and under what
circumstances (other than needing to be a Brazilian citizen,
on-location at the headquarters of ITI) would it not be illegal to do
so? (I think I can guess why this would this be so -- so that
internal business isn't aired like dirty laundry to the rest of the
world -- but in this case, I think the world needs your example.)
>> > ICP-Brasil is budgeted to have an independent
>> > audit performed in 2010. The sub-CAs are also working on independent
>> > audits, which will be available in 2010. ICP-Brasil has requested that
>> > we move forward with processing this request, with the understanding
>> > that the audits are forthcoming.
>>
>> OK. My view only, and no doubt others have other views:
>
> The problem is that the ITI is an agency that depends on the federal
> budget.
> The audit which we refer to is only the CA-root. The remaining audits
> in sub-CA happen without restrictions annualy.
So... the CA root is currently audited by other governmental agencies,
but because we evidently don't even trust governments to govern
themselves appropriately we're demanding a... private-party audit of a
governmental office?
This strikes me as strange.
>> I think I would be favourable on this if all certs and sub-CAs are
>> within the government sphere (according to some definition).
I think I'm favorable on this, even without an "external" audit (trust
me, the GAO is definitely "external" to any governmental organization
it swoops in on; there's absolutely no reason to assume, believe,
think, or even entertain the notion that different agencies of a
democratically-elected government are in cahoots with each other, when
at least one of the agencies is tasked solely with auditing).
>> I think I would be favourable on this if we could identify who takes the
>> responsibility for a flaw, a breach or a badly issued cert. If for
>> example there were a clear breach of a cert, is it entirely clear who
>> pays the money for any losses?
Again, my only question on this request: Why are you not requesting
the S/MIME mail protection bit as well?
-Kyle H
Kyle Hamilton
How can non-citizens get access to the root's audit reports? That's
the biggest problem we've got, is that nobody on this list (except for
you) is a citizen of Brazil, and we can't simply take your word for
it.
If a third-party audit report would not be confidential, I recommend
that this request be tentatively approved pending receipt of that
report noting no major flaws. If such a third-party audit report
would be confidential, though, then what's the point?
-Kyle H
On Mon, Dec 7, 2009 at 8:41 AM, Ruy Ramos <ruyram...@gmail.com> wrote:
Kyle Hamilton
> Hi Kyle,
>
> I think the issues that came up last Xmas are really important. But I don't
> support using them to fight reputation wars, and I don't like encouraging
> people to do that on this list. I think it would be far better for us to
> talk in the abstract, e.g. CA Acme.com had a breach because its reseller
> made a mistake (or whatever).
>
>
> On 04/12/2009 20:02, Kyle Hamilton wrote:
>>
>> On Thu, Dec 3, 2009 at 3:25 PM, Ian G<ia...@iang.org> wrote:
>
>> I look at it this way: certifying authorities are essentially trying
>> to act like digital notaries.
>
>
> This is a view. Nobody's going to challenge it until some money is on the
> table. And then, as soon as money is on the table, I predict that view
> won't be worth the money ;) CAs are nothing like digital notaries.
>
> (Although, perhaps you mean Notary Publics? That's a closer fit, but even
> then, they are nothing like that, they are more like garages that also
> deliver car-safety certificates.)
We already have garages that issue smog-compliance certificates. We
also have garages that do "many-point inspections".
Though I did mean Notary Public.
>> The CA in question, if viewed as a
>> notary, essentially allowed someone else to fill in its logbook, and
>> blindly rubber-stamped and signed (the two separate affirmative
>> actions that a notary must make before a notary's signature is
>> accepted as an attestation), a document essentially stating that the
>> controller of the mozilla.org domain asked it for presentable,
>> verifiable evidence that the webserver was, in fact, run by the
>> controller of mozilla.org, as attested by an uninterested, and thus
>> more inherently trustworthy, third party. (I'm reminded of the quote:
>> "A commercial CA protects you from anyone whose money it refuses to
>> take." -- attributed to Matt Blaze in an RSA2000 hallway discussion.)
>
>
> And that's another view. Which the CAs will aggressively attack, and lead
> you to believe that the "notary view" is better.
Technically, several are already accepted as providing identity
services that are at least as good as notaries -- in California,
anyway.
> But, Matt Blaze probably had good reason to say that, and the fact that it
> became a famous aphorism indicates that many people think it on target.
What's a commercial CA going to do, say "I'm not going to take your
money because you can't prove you're who you say you are"?
>
>
>> ... The fact that
>> there is an arbitration (with Frank handing over the reins to Kathleen
>> while still making sure that if she makes some... very strange mistake
>> (which I would call 'strange' simply because she's been very excellent
>> at keeping track of things -- thanks again, Kathleen!)) means that the
>> arbiter *must* be neutral.
>
>
> I proposed Arbitration or a method akin to it a while back, indeed my
> thoughts were directed from the Xmas incident, to try and reduce the damage
> done in that event. Do you think Arbitration might be a good idea?
What is at dispute? Mozilla already retains final say on what's in
its products.
I wish there were a formal process for investigations into alleged
mistakes. Of course, if I'm making wishes, I might as well wish that
such a process involved a mandatory report of what happened to
Mozilla, abstracted at most to a level of detail related to what part
of the process was violated, what company was responsible for
violating it (such as in the case of RAs), what the potential scope of
the problem is (such as, "how many of what types of certificates were
issued through the same mechanism that allowed the process to be
violated", optionally with an estimate [rounded to the next highest
5%] of the percentage of certificates in end-user hands are
potentially affected, and approximately how many web servers, email
clients, and code signers would be adversely affected by the removal
of trust bits); how it was possible for the process to be violated,
and the things that are being done to prevent the same mistake in the
future, and anything else that's pertinent, including details of the
contractual obligations that the root-CA expects from any RA or
sub-CA.
The report provided to Mozilla can be further abstracted as necessary
to keep business details private, but that abstracted report should be
provided to the community as part of the bug tracking the incident.
> (I don't know what you mean by ... very strange mistake, I've not noticed it
> myself.)
I haven't noticed her make any mistakes, either. Which is why it
would be very strange. ;)
(Maybe I should have used the term 'uncharacteristic', because it
truly would be uncharacteristic of Kathleen to be anything less than
meticulous in obtaining, collating, abstracting, and presenting the
information that we typically first ask for in the process of
evaluating other CAs. She is a gem -- I don't know how Mozilla found
her, but they need to keep her.)
-Kyle H
Ruy Cesar Ramos Filho
> On 12/05/2009 05:09 PM, Eddy Nigg:
>> Kathleen, this request would take me way more than a week to review.
>> Can we work out a different approach as suggested above (either way
>> would be fine, the later would perhaps allow for inclusions of the
>> individual CAs faster, the former might be blocking the whole process
>> eventually).
>
> After reading a bit more through
> https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=414133 I
> believe to know the possible answer already. As Ian (I think) noted
> already, ICP/ITI is auditing itself, I believe that we can not accept
> an auditor also as a CA root.
>
The ITI not audit itself.
The Committee-Manager appointed by the President of Brazilian Republic
have this assignment.
https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=342612
> There are some countries in which a national CA, sub or cross signs CA
> roots operating in their jurisdiction, but these subordinated CAs have
> been treated usually individually. In my opinion, the ICP root can not
> be included because it is also the auditing authority. With that I
> suggest to schedule the inclusion process for each individual CA (most
> information gathering has already been done) and probably accept ITI
> as an acceptable auditor according to the Mozilla CA policy, treat the
> requirements of ICP as binding for any of the CAs under its regime -
> but still reviewing each CAs CP/CPS and require audit statements for
> each CA.
>
You can include the sub-CA of ICP-Brasil but this does not solve the
problem of thousands of Firefox's users in Brazil. The only reasonable
that the root-CA is included and that the other sub-CA be treated by the
attribute AIA.
Eddy Nigg
> Eddy Nigg escreveu:
>> On 12/05/2009 05:09 PM, Eddy Nigg:
>>> Kathleen, this request would take me way more than a week to review.
>>> Can we work out a different approach as suggested above (either way
>>> would be fine, the later would perhaps allow for inclusions of the
>>> individual CAs faster, the former might be blocking the whole
>>> process eventually).
>>
>> After reading a bit more through
>> https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=414133 I
>> believe to know the possible answer already. As Ian (I think) noted
>> already, ICP/ITI is auditing itself, I believe that we can not accept
>> an auditor also as a CA root.
>>
> It's not true! I think that is a little bit confusion.
> The ITI not audit itself.
>
> The Committee-Manager appointed by the President of Brazilian Republic
> have this assignment.
> https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=342612
Unfortunately I can't read it :S
But it is my understanding that ICP is government appointed or operated
national CA audited by the national Institute of Information Technology.
That's the same thing.
PS. For some unknown reason I receive an
ssl_error_handshake_failure_alert after adding an exception for
https://www.icpbrasil.gov.br/
>
> You can include the sub-CA of ICP-Brasil but this does not solve the
> problem of thousands of Firefox's users in Brazil. The only reasonable
> that the root-CA is included and that the other sub-CA be treated by
> the attribute AIA.
I don't understand the argument. If some or all CAs are reviewed and
admitted to Firefox, why shouldn't this help the thousands of Firefox
users in Brazil?
Frank Hecker
> How can non-citizens get access to the root's audit reports? That's
> the biggest problem we've got, is that nobody on this list (except for
> you) is a citizen of Brazil, and we can't simply take your word for
> it.
I may not have been reading closely, so feel free to correct me: My
impression is that the "audit report" being referred to as confidential
is a full internal report with details of operations that might be
considered sensitive, while the "audit report" we are requesting is more
analogous to a WebTrust report that simply confirms operation of the CA
according to the CPS. I am reminded of the situation with the French
national CA, where there was a similar confusion over whether we were
requesting a government-classified document or not.
> If a third-party audit report would not be confidential, I recommend
> that this request be tentatively approved pending receipt of that
> report noting no major flaws. If such a third-party audit report
> would be confidential, though, then what's the point?
If ICP-Brasil does a third party audit, e.g., using a
WebTrust-authorized auditor, then I would expect that ICP-Brasil would
publish a standard WebTrust (or similar) report just like any other CA
that gets a WebTrust audit.
Frank
--
Frank Hecker
hec...@hecker.org
Eddy Nigg
> If ICP-Brasil does a third party audit, e.g., using a
> WebTrust-authorized auditor, then I would expect that ICP-Brasil would
> publish a standard WebTrust (or similar) report just like any other CA
> that gets a WebTrust audit.
Correct, I suspect there is no audit statement so far.
Ian G
> On 3 dez, 00:44, Ian G<i...@iang.org> wrote:
>> On 26/11/2009 01:51, Kathleen Wilson wrote:
>>
>>> * These root certificates are used to secure Brazilian government and
>>> financial sites.
>>
>> 1. What does "financial" mean in this context?
>>
>> 2. Can we confirm that all certificates are issued within the Brazilian
>> government?
>
> I think there is a little bit confusion sometimes because any
> incomplete translations on our part.
Sure. The problem here is that although the ICP-Brazil is dealing with
a local market of Brazilian certificate users, the damage is done to
relying parties and end-users, which latter are not limited to the local
circumstances. It is that latter group to which we look.
> We will try to better clarify:
> a) The ICP-Brazil is a national system of digital certification
> defined in law (MP 2200-2 /2001). Known as Brazil's National PKI (ICP-
> Brasil). Digital certificates by ICP-Brazil should / can be used by
> any sector of the economy, not just government or financial
> institutions
Hmmm... Is this modelled after or in any way comparable to the European
model following the Qualified Certificate digital signing directive?
What is the status of a CA that is not inside the ICP-Brazil ?
> b) In this system there are several actors: Committee-manager of ICP-
> Brazil,
(Name in Portuguese?)
> CA-Root, sub-CA, among others (RA, PSS). The Committee-manager
> has several responsibilities among the main agree on standards for ICP-
> Brazil and audit/review the CA-Root. All members are appointed
> directly by the President of Brazil.
OK. Who does the actual practial work of the audit? Presumably not the
Committee or the manager. Is there an audit committee formed? Does it
include people from the traditional audit organ of government?
(In the USA this is called OMB or Office of Management of Budget.)
(I see a potential answer is below.)
> The ITI is a Brazilian government
> agency that operates the CA-root. The ITI has no vote in the Committee-
> manager. The ITI has 2 boards: one to operate the Ca-root and one for
> audit/check/supervise the sub-CA (1� and 2� level). ITI is not self-
> audits . In 2010 there will be CA-root audit by an external company as
> determined Committee-manager.
Does the above CA-root audit ordered by the Committee-manager also
include the audits done by ITI's audit board over the sub-CAs?
> The ITI ( government agency) is not
> required under Brazilian law to undergo an external audit
Fine. I have no issue with that. This is standard government practice.
> since it is
> audited by other government agencies (TCU and CGU).
Aha - Bingo! Who are these people? tip tap: I get this:
http://portal2.tcu.gov.br/portal/page/portal/TCU/english
http://www.cgu.gov.br/english/
And linked-in for what it is worth:
http://www.linkedin.com/companies/brazilian-office-of-the-comptroller-general-cgu-
So CGU is the comptroller-general. I don't fully understand what TCU is
(it's something like the auditor for government, but it's something like
the association for auditors as well?) but either way, it has the
characteristics to pass Mozilla's paras 10,11.
> c) We can say that all the certificates in the chain ICP-Brazil are
> ultimately guaranteed by the brazilian federal government. As the root-
> CA is operated by ITI (government agency) any damage caused to third
> parties must be repaired. This is the Federal Constitution (1988),
> �Article 37. The government directly and indirectly from any of the
> powers of the Federal, State, Federal District and municipalities will
> follow the principles of lawfulness, impersonality, morality,
> publicity and efficiency, and also to the following: � 6 -
> Corporations Law public and private providers of public services are
> liable for damages that their agents, as such, cause to third parties,
> ensuring the right of recourse against the responsible in cases of
> fraud or negligence.�
>
> d) And so: MP 2200-2 (law), August, 24 2001 say:
> �Art.10 � Are considered public or particular documents, for all the
> legal purposes, the electronic documents treated by this law.
> �1� The declarations within the documents in electronic means produced
> with the use of certification process provided by ICP-Brasil are
> presumed true regarding its signators, in the form of article 131 of
> the law 3.071 01/01/1916 � Civil Code.�
OK. This is very interesting. So this is closer to the QC model in
Europe, where the protection has teeth on paper at least, unlike the
USA/WebTrust model.
Now, the next question is: can we (pursuant to policy para 11) trace
that to the end-user?
That is, can you point to something in the ICP-Brasil documentation that
states (I'm making this up here):
Each sub-CA must include in its Relying Party Agreements a clause
that informs the RP that certificates so-issued are protected
according to Article 37, MP 2202-2, etc.
Each sub-CA must include in its RPA a clause that establishes
the means by which an RP seeks damages to be made good
(for example, selection of courts, Arbitration, etc).
Each Sub-CA must include in its RPA clauses that express
total liabilities as either unlimited or limited.
(etc etc) The above chain is not what I'm asking for ... rather I'm
asking whether there is a chain that allows us to trace what it is the
end-user and the relying party is looking at.
>> 8 Sub CAs. As far as I can see, Certisign and Caixa are commercial
>> companies ... so let's narrow this down:
>>
>> Are some of the sub CAs non-governmental?
>
> Caixa: bank (public bank)
> SERASA: commercial
> Certisign: commercial
> AC-jus: Justice/judiciary
> AC-RFB: Brazilian IRS Dept. (government)
> AC-PR: Presidency of Brazil
> AC-IMESP: S�o Paulo government agency
> AC-SERPRO: TI company (public)
OK. So is there a restriction on membership? Is it restricted for
example to "public organs and private organisations that are heavily
regulated by national regulators" ?
E.g., can the electricity company become a CA under ICP-Brazil? Can I
fly into Brazil and sign up? Can a Favela get in?
The reason we ask this is because in accepting ICP-Brazil, we have to
assume we also accept, without exception, any of your choices over the
next many years. I don't mind so much who they are, but the selection
criteria is "material" to Mozilla's process.
>>> * OCSP: There is no OCSP support at the root level. If a sub-CA
>>> supports OCSP, then their CPS must state so in section 4.4.11. It does
>>> not appear that any of the sub-CAs currently provide an OCSP service
>>> under this root.
>>
>> OK, can we request a statement on their plans on this? (I'm only asking
>> to speed up the inevitable request.)
>
> The OCSP should be adopted soon to attribute AIA. In the first half of
> 2010.
For me this is not problem. For me this will likely effect your
customers, it doesn't create additional risks, as reduce existing ones
(e.g., customers forgetting to local CRLs), so it is between you and
your customers.
But others in Mozilla open forum see it differently.
>>> * Audit: ITI has an audit committee that has been performing annual
>>> audits against the Brazilian standards, which are equivalent to ETSI
>>> TS 101 456 and ETSI TS 102 042. ITI also audits the sub-CAs annually.
>>> The second-level sub-CAs and the RAs are either audited by ITI or by
>>> an independent auditor accredited by ITI.
>>
>> OK, so all second-level sub-CAs are audited. I note that there is some
>> suggestion here that the audits may not be fully independent. But I
>> don't see a need to raise a flag on that one.
>>
>>> The audit reports are
>>> currently confidential.
>>
>> This however is more of an issue.
>>
>> Do we know why this is?
>>
>> What does confidential mean? To whom? If I get into a dispute with one
>> of the CAs, can I see the audit report?
>
> The audit reports of CA-root are sensitive when it comes to
> advertising.
! I think that is a non-reason, and I'm somewhat bemused by the
fig-leaf characteristic of it. But let's politely move on :)
> However, any interested citizen may refer to any process
> at the headquarters of ITI without any restrictions.
It sounds to me that you are saying they are not confidential, but
rather they are simply unpublished in a public forum, and a citizen has
to go to the office in order to request a copy? Like court filings used
to be in the anglo world.
So, why can't we have an interested citizen go to the office, extract
the audit reports, and either send them back to us, or send us a
second-hand report over them?
> In the case of
> reports of sub-ca, ITI publishes in the Diary Official of Brazilian
> reported that a certificate provides sub-CA has been audited and is
> operating according to standards (CP/CPS).
OK, what we would call the Official Gazette, likely. So the ITI takes
responsibility for the audit being good, by publishing the statement.
This is good.
>>> ICP-Brasil is budgeted to have an independent
>>> audit performed in 2010. The sub-CAs are also working on independent
>>> audits, which will be available in 2010. ICP-Brasil has requested that
>>> we move forward with processing this request, with the understanding
>>> that the audits are forthcoming.
>>
>> OK. My view only, and no doubt others have other views:
>
> The problem is that the ITI is an agency that depends on the federal
> budget.
> The audit which we refer to is only the CA-root. The remaining audits
> in sub-CA happen without restrictions annualy.
OK. (I'm guessing you mean "without exceptions".)
>> I think I would be favourable on this if all certs and sub-CAs are
>> within the government sphere (according to some definition).
OK, this is a NO.
>> I think I would be favourable on this if we could identify who takes the
>> responsibility for a flaw, a breach or a badly issued cert. If for
>> example there were a clear breach of a cert, is it entirely clear who
>> pays the money for any losses?
>>
>
> The chain of responsibility starts in the sub-ca (2� level. 1� level)
> and should reach the CA-root. Remember, if there are problems
> characterized in the root certificate so the Brazilian government pays
> for the damage. If fraud is found or any other problem that causes
> some loss to the citizens, the Brazilian government can be held
> responsible, ultimately.
>
> The sub-CA is obliged to issue an insurance policy that guarantees the
> repair of damage to users.
That's the sort of clause we need!
So this is a YES.
My view right now is that if ICP-Brazil can establish a clear chain from
root -> sub-root -> sub-root(2) -> certificate subscriber -> relying
party, and that chain has teeth, then this is good.
Secondly, if there is an ability for us to view the audit reports,
either by having someone send us a copy, or by us delegating a Brazilian
citizen to report 2nd hand, then this is also good.
The question of whether the government audits itself is irrelevant, as
is the general sense of "independent audit" being an external big-4
auditor. The question is, rather, what steps are taken to ensure that
the audit is done to reasonable professional standards, such that the
reading community can rely on it. C.f., Policy 10 3rd point. If the
government has established this in any sense, then this is good.
Above you say that the committee-manager does the audit of the top root
in ITI. What is the relationship betweem that act and the CGU and TCU?
If the committee-manager appoints in some sense (including the notion
of appointing advisors) the latter bodies, this would be good.
Can you clarify these three issues?
Given "good" results to all those questions, my advice to Mozilla would
probably be thumbs up. Given "bad" results, probably thumbs down. If
there is a mix, let's examine that.
iang
Ian G
> Er, waitaminute. *rinses eyes* *rereads*
>
> Is this the first CA that actually *accepts* liability, not only for
> itself but also for the actions of its sub-roots?! i.e., an agent
> only has legitimate access to the signing key of any CA in the
> hierarchy when he is in the role of agent as such, and doesn't have
> access when when he isn't... which means that in any action of fraud
> or negligence committed by him -- say, to issue a personal certificate
> in someone's name to someone who wasn't entitled to it, either through
> willful malfeasance or through just not checking as thoroughly as
> necessary -- is ultimately up to the government to be liable for the
> fraud, beyond the extent of the liquidity of insurance provided by the
> sub-CA itself?
>
> Wow. *THAT'S* something that a digital signature law should include, folks.
Interesting indeed. Let's be cautious and not ascribe it necessarily as
a good thing, though. Plenty of governments have gone in and broken
things, like in Europe. Keep testing it ...
One clear difference between Europe and Brazil is that the CAs chain up
to a central root in the latter. Which ... is reflected in the chain of
liability.
iang
Ian G
>>> I think I would be favourable on this if all certs and sub-CAs are
>>> within the government sphere (according to some definition).
>
> I think I'm favorable on this, even without an "external" audit (trust
> me, the GAO is definitely "external" to any governmental organization
Right, GAO, that's what I meant to write when I said OMB. Being a
daft-furriner, I frequently get confused by all them TLAs.
> it swoops in on; there's absolutely no reason to assume, believe,
> think, or even entertain the notion that different agencies of a
> democratically-elected government are in cahoots with each other, when
> at least one of the agencies is tasked solely with auditing).
Exactly. I have no idea how it is in Brazil, but I would be surprised
and shocked if a private 3rd party firm would do better.
iang
Ruy Cesar Ramos Filho
> Kyle Hamilton wrote:
>> How can non-citizens get access to the root's audit reports? That's
>> the biggest problem we've got, is that nobody on this list (except for
>> you) is a citizen of Brazil, and we can't simply take your word for
>> it.
>
> I may not have been reading closely, so feel free to correct me: My
> impression is that the "audit report" being referred to as
> confidential is a full internal report with details of operations that
> might be considered sensitive, while the "audit report" we are
> requesting is more analogous to a WebTrust report that simply confirms
> operation of the CA according to the CPS. I am reminded of the
> situation with the French national CA, where there was a similar
> confusion over whether we were requesting a government-classified
> document or not.
>
Ruy Ramos
Kathleen Wilson
Thank you for your contributions to this discussion. Your efforts are
greatly appreciated.
I would like to see this discussion move forward in attempting to
answer these questions: If ICP-Brasil’s upcoming audit meets Mozilla
CA Policy and does not find significant problems, then should the ICP-
Brasil root be approved for inclusion? If not, what are the concerns/
issues that would prevent inclusion of the root?
Note 1: If the root is not approved for inclusion, then ICP-Brasil may
proceed by having each sub-CA apply for inclusion separately as
separate trust anchors. This approach has been and is being taken for
some other government CAs.
Note 2: I have checked with others (such as Nelson), and received the
following recommendation: "I would argue that it's best for the users
if the decision to exclude a root and admit (some of) its subs is a
one way door, not to be revisited and undone." Therefore, let's not
make a decision to exclude a root under the assumption that the root
could later be re-considered and approved/included.
I have summarized information about the sub-CAs here:
https://bug438825.bugzilla.mozilla.org/attachment.cgi?id=391429
Requirements regarding constraints on the tier 1 sub-CAs issuing tier
2 sub-CAs are determined on a per-sub-CA basis. E.g. Whether or not
subordinate CAs are constrained to issue certificates only within
certain domains, and whether or not subordinate CAs can create their
own subordinates.
The following tier 1 sub-CAs either have not issued tier 2 sub-CAs or
have only issued tier 2 sub-CAs for internal purposes:
Caixa: bank (public bank) – has only issued internal sub-CAs.
AC-SERPRO: TI company (public) – has only issued internal sub-CAs.
Certisign: commercial – has not issued sub-CAs
AC-PR: Presidency of Brazil – has not issued sub-CAs
AC-IMESP: São Paulo government agency – has not issued sub-CAs
The following tier 1 sub-CAs have signed tier 2 sub-CAs for use by
external organizations:
SERASA (commercial) has issued 2 internal and 1 external sub-CAs.
AC-SRF (government) is an authority of standards and politics. The end-
user certs are issued by external entities that operate sub-CAs (2º
level): AC-Serpro-RFB, AC-Certisign-RFB, AC-Serasa-RFB, ACImprensa-
Oficial-SP-RFB, AC-Prodemge-RFB, AC-Sincor-RFB, AC-Notarial-RFB, AC-BR-
RFB.
Audit position as of November 2009:
http://www.iti.gov.br/twiki/pub/Certificacao/AuditoriaIndependente/processo_fiscalizacao.pdf
AC-jus (Justice/judiciary) Jus is an authority of standards and
politics. The end-user certs are issued by external entities that
operate sub-CAs (2º level): AC-Serpro-Jus, AC-Certisign-Jus, AC-Serasa-
Jus, AC-Caixa-Jus.
The question about selection process for sub-CAs needs to be answered
at both the tier 1 and the tier 2 level:
> So is there a restriction on membership?
> Is it restricted for example to "public organizations and private
> organisations that are heavily regulated by national regulators"?
> E.g., can the electricity company become a CA under ICP-Brazil?
> Can I fly into Brazil and sign up? Can a Favela get in?
> The reason we ask this is because in accepting ICP-Brazil, we have to
> assume we also accept, without exception, any of your choices over the
> next many years. I don't mind so much who they are, but the selection
> criteria is "material" to Mozilla's process.
At the root level, requirements are in place for all sub-CAs within
the hierarchy in regards to verification of domain ownership/control.
The CPS states that each of the sub-CAs CPS documents must have the
following in sections 3.1.11 and 3.1.11.2: "For certified equipment or
application using the URL field Common Name must be verified if the
applicant holds the certificate of registration of domain name with
the competent body, or has permission from the owner field to use that
name. In this case must be presented documentation (term of
authorization for use of domain or similar) signed by the holder of
the domain."
The tier 1 sub-CAs that sign tier 2 sub-CAs also have this requirement
on the CPS of the tier 2 sub-CAs.
There was a question in the discussion about why ICP-Brasil isn’t
requesting the email trust bit. The reason is because supporting e-
mail address is optional to ICP-Brasil, so the CPS does not state the
requirements for sub-CAs in regards to verifying ownership/control of
the email address.
There was another question in the discussion about delegation of
verification procedures. Some of the tier 1 sub-CAs delegate the
verification of domain ownership/control to third parties. From one of
the sub-CAs: "In Brazil, Registration Authorities (RA) perform such
functions. According to ICP-Brasil regulation, RA contracts and
conducts their own audit process, but the audit reports are presented
to the related CA."
As stated earlier in this post, I will greatly appreciate your input/
help in discussing these questions: If ICP-Brasil’s upcoming audit
meets Mozilla CA Policy and does not find significant problems, then
should the ICP-Brasil root be approved for inclusion? If not, what are
the concerns/issues that would prevent inclusion of the root?
Kathleen
Kathleen Wilson
aren't yet showing up. The last posting I can see (before mine) was on
Dec. 8.
Kathleen Wilson
There are three possible outcomes of this discussion. I will summarize
them in no particular order.
Possible Outcome #1 – Deny root inclusion, proceed with evaluating the
individual sub-CAs as potential trust anchors in NSS
Possible Outcome #2 – Move forward with the root inclusion request
after the upcoming audits have been completed and confirmed to meet
the requirements of the Mozilla CA Policy.
Possible Outcome #3 – Accept the root inclusion request after the
auditors of the recent audits provide public-facing statements,
meeting the requirements of Mozilla CA Policy.
The concerns about including this root are as follows.
Concern #1) The large hierarchy of externally-operated sub-CAs. Some
of the sub-CAs also have externally-operated sub-CAs and also delegate
end-entity verification procedures (eg DV/OV) to RAs.
Rebuttal:
a) There are strong requirements that sub-CAs must meet before
accreditation as an authority in this hierarchy.
*DOC-ICP-03 <http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-
ICP-03_-_versao4.2.pdf>
* Critérios e Procedimentos para Credenciamento das Entidades
Integrantes da ICP-Brasil - *v.4.2
( * http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-03_-_versao4.2.pdf
)
b) The ICP-Root CA and the Brazilian government have strong legal and
financial incentives to be extra cautious about approving CAs and RAs
in this hierarchy. Under the law quoted (from the Brazilian
Constitution, no less), the Brazilian government takes responsibility
not only for the actions of the ICP issuing the CAs that it accredits,
it also takes responsibility for the actions of the CAs that it
accredits.
c) According to ICP-Brasil regulation, RA contracts and conducts their
own audit process, but the audit reports are presented to the related
CA. The CA must ensure that the RAs are also performing their
verification procedures as per the CPS.
Concern #2) There is the possibility that not all of the sub-CAs
chaining up to this root would be approved for inclusion if they were
evaluated separately.
Rebuttal:
a) The CPS documents of the sub-CAs have been made available.
b) It has been confirmed that the CPS documents include requirements
to verify that the end-entity cert subscriber owns/controls the domain
name to be included in the cert.
c) It has been confirmed that the CPS documents include both DV and OV
requirements for issuing SSL certs.
d) The sub-CAs have provided the requested information and have all
reviewed the list of Potentially Problematic Practices.
e) The sub-CAs are audited annually.
Concern #3) This structure appears similar to the European structure –
the approach there was to not approve the root for inclusion, and to
evaluate each sub-CA separately.
Rebuttal:
a) In this hierarchy, the sub-CAs chain up to a clear root and there
is a clear chain of liability.
Concern #4) If one of the sub-CAs does fail to operate their CA at a
sufficient level of quality, then the only recourse Mozilla could take
would be to disable the root, affecting a large number of end-users.
If the sub-CAs are evaluated and included separately, then Mozilla
could just disable that particular sub-CA.
Rebuttal:
a) This concern can be made for many roots with externally-operated
sub-CAs. The difference with this hierarchy is that it is so large.
(See Rebuttals to Concern #1).
Concern #5) Currently no public-facing audit statements/reports.
Rebuttal:
a) ICP-Brasil has planned to have third-party audits of its root and
all of its sub-CAs in early 2010. ICP-Brasil is not requesting
inclusion until those audits have been performed and accepted as
meeting the requirements of the Mozilla CA Policy.
Note: there has been discussion that the current audits that are
performed by DAFN/ITI or Independent Audit (http://www.iti.gov.br/
twiki/bin/view/Certificacao/AuditoriaIndependente ) could be
considered sufficient, as long as they also produce a public-facing
document about their audit results.
This is a lot of information to consider, so I am going to leave this
discussion open a while longer while I seek guidance.
In the meantime, I will start the discussion for the next root
inclusion request that is in the queue.
Thanks,
Kathleen
Kathleen Wilson
ICP-Brasil root inclusion request.
We have decided to take the approach to include the ICP-Brasil root if
the upcoming audits meet Mozilla CA Requirements, cover all of the sub-
CAs, and find no significant deficiencies.
While the hierarchy under this root is large, we should be able to
approve the root as long as we have adequate information on all sub-
CAs in terms of their meeting requirements and being under a
reasonable audit and regulatory regime. Having the upcoming, third-
party audits will provide some additional assurance that the overall
hierarchy is being run properly.
The action items resulting from this discussion are as follows:
ACTION ICP-Brasil: Proceed with the upcoming audits that have been
planned and budgeted. Please make sure that these audits meet the
requirements of sections 8, 9, and 10 of the Mozilla CA Policy,
http://www.mozilla.org/projects/security/certs/policy/.
ACTION ICP-Brasil: Update the bug to provide links to the public-
facing audit reports/statements for the root and the sub-CAs, as those
audits become available.
ACTION Kathleen: If the audit statements are not posted on a third-
party website such as cert.webtrust.org, then follow the Mozilla
process to do an independent verification of the authenticity of the
audit statements.
ACTION Kathleen: After the audit statements for the root and sub-CAs
have been provided and verified, start the second round of public
discussion.
I will post these action items in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=438825
I am now closing this discussion. Any further follow-up on this
request should be added directly to the bug.
Thanks,
Kathleen