Re: Izenpe Root Inclusion Request
Iñigo
> > I would strongly disagree with that. Port 80 has been defined for the
> > HTTP service. 8097 not.
>
> Well, you right, IANA has defined the port 80 for http, as well as few
> other ones: 591, 8008, 8080. It’s also interesting to see how IANA
> agree to use many other port that use http fortransport for other
> protocols (the list is huge).
>
> At this point I would like also to highlight that the OCSP protocol as
> defined in the RFC2560 is transport protocol agnostic:
>
> “The actual formatting of the message could vary depending on
> the transport mechanism used (HTTP, SMTP, LDAP, etc.).”
>
> So what it’s required to use in the AIA extensión is an URI, what if
> instead of using http/s someone decide to use SMTP, LDAP, SOAP, etc,
> will mozilla implement all posible transport protocols?
>
> I’m fully agree that http/s is the best option and the one to be
> followed and that well-know ports should be used to avoid future
> problems but this should be write it down in a clear specification
> otherwise I don’t see point to put anyone under others pesonal's
> criteria.
>
> > Their OCSP responder wasn't even compliant and didn't worked for eight
> > years for Mozilla Firefox.
>
> I’ve just test it and it works fine, the only think is that I had to
> include the Izenpe hierarchy into Mozilla manually and then test it.
>
> > These days OCSP response is used for almost all SSL secured sites -
> > indeed very unusual. Corporate firewalls however regularly block
> > anything beyond a few allowed ports.
>
> Have you try it to put the AIA extension has critical? This will force
> that the certificates should be checked but when I tried most of the
> products reject the certificates. So, I’m afraid this is not really
> true, just I would like to explain the situation we have in Spain.
>
> Here we have a nice National ID Card -16 millions cards have been
> issued, by the way 16 million of people that need to include the DNIe
> root manually in Mozilla if they want to use the browser-, also there
> is a couple of laws that force to the Government and the companies to
> provide authenticated access with certificates to the services. Well,
> most of the companies that implemented have need to create their own
> mechanism to verify the status of the certificates –either using OCSP
> (the least) or DSS (the most)-.
>
> > I would suggest to move the OCSP responders to port 80 and leave a
> > shadow service for the previous ports. The previously issued
> > certificates will probably expire within reasonable time and the new
> > certificates will be directed to the regular ports. I think this should
> > be the correct action and solution.
>
> Fully agree, I would like also to SUGGEST this change rather than to
> impose. I would kindly ask to Izenpe to reconsider it’s current port
> for those “general users” certificates, I assume after see the kind of
> certificates they issued –most for public employees- they have not
> problem in the Basque Government network to use any port.
>
> Regards,
> Emanuel
Hi all,
I will try to sumarize all that you have been posting here. There are
some comments that in my opinion are out of this scope and are
suggesting things that I don´t like at all.
As Kathleen has suggested, there are 2 items opened, OCSP (although
this one has been set as action:none) and email.
1.- OCSP
There are so many things that it´s complicated to reply and not forget
something, but, here I go.
The answer from Kathleen on 14/6 is correct, and the same from
etowers. I´m agree with them, but in order to answer Kurt´s and Eddy´s
concerns, this is what I have to say:
- Izenpe runs their PKI services, not the government. Maybe I didn´t
explain very well, but I have never said that we don´t run or manage
the PKI, our CAs and RAs. That´s something you have guessed and I don
´t like that. Of course we control all of our CAs, RAs, services, etc.
What I meant is that we´re in the same infraestructure than the
government and that´s it. And because of that, some infrastructures
are shared, period.
- About the audits, well, I´m totally agree with etowers. I can´t
believe that you said that being certified is just passed and audit. I
´m not certified in "painting houses", but in ISO 27001, ETSI 101 456
and Webtrust for EV. What you say is despise everything because you
may say you don´t trust any of these certifications, and of course,
any of the auditing bodies, in our case, BSI and KPMG. But, on the
other hand, I have to follow "your" recommendations or suggestions.
Ok, fair enough. Mozilla has asked my certifications, why then? Does
not Mozilla trust them as you may suggest? Must Mozilla trust you
much more than the standards?
Kurt, this is really disapointing me and I don´t know the reason.
- About the ports, in answer to Kurt, I don´t see why you regard this
as problematic. Kathleen´s said it´s not an issue. If Izenpe´s OCSP
responder is unreachable, either because it is down, or because the
port number to run it is blocked, then our certificates will not pass
a revocation check and therefore will not be trusted.
If the port number is a practical problem (and I don´t think it is)
then you could argue that it damages Izenpe´s ability to do business,
but that is no threat to Mozilla users? Or are you saying that Mozilla
would treat an unreacheable OCSP responder the same way that it would
treat a succesful OCSP query with a GOOD response?
To Eddy, I was wrong, our VA is not using the port 80 , there´s
nothing configured there. But you can´t say if our infraestrucure will
not be able to mange the load because you don´t know our
infraestructure. About using that port, well, in year 2002 when Izenpe
started, that decision was taken, maybe it wasn´t a good one, but this
is what we have.
Our OCSP is working for Mozilla users as Kathleen has said when you
enforce, and if you "insert" the CAs in the browser of course it works
and has been doing for the last 8 years, but of course, not by
default, because we are not yet in the Mozilla root program and this
is the fight we´re having in the last 4 years.
2.- email trust bit
Initially, I have no idea what you were asking so I had to go a bit in
deep of all the Izenpe certificates. We have 21 profiles and this is
what I found:
- We have only one certificate profile for general users/citizens
(ciudadano/ONA) and this profile is just for "client authentication"
such as it´s identified in the extedendKeyUsage and in the
netscapeCertType. The email atribute is not used in this profile so it
can not be used for email
- We have some other profiles that include the emailProtection and
smartCardLogon flags into the extendedKeyUsage. These are the
corporate ones (public and privates) and the ones for the civil
servants. Those certificates are issued as mentioned above to the
public employees or civil servants of the government, there´s a
registration procedure that require a positive identification of all
the data contained in the certificate. As mentioned, of course, we
take all the measures to check everything. Besides, the employee has
to sign a contract for which he/she is liable for the identity
information provided. Again, following the current legislation. Also,
during the registration procedure, it´s verified all the identity
informaion provided by the public employee, including the email that
belong to the organization. These procedures have been reviewed by the
auditors in the assesments, if you trust such audits.
- There are some other certificate profiles that use the
emailProtection, and those are "technical ones", like application,
seal, site. These certifcates are quite similar to SSL web server
certificates and they follow the specific spanish legislation (law
11/2007 for the electronic public administration). These kind of
certificates are used to digitally sign on behalf of the "public
administration" not for a person. The procedure to issue these
certificates is the same in which we check that the email address
provided by the institution belong to its domain and it exists.
RaminS
since this is my first reply please forgive if it is not complaint to
all your guidelines.
Here in Austria we had a similar issue with OCSP not listening on a
standard port. As already mentioned some firewalls did block these non
default ports – as far as we could reverse engineer the problem if the
firewall DENYed the package the browsers ‘just’ didn’t get an answer,
but when the package was DROPed, the browser waited until a timeout
had been reached, which resulted in slow page loading when our
certificates were used for SSL.
We would have been happy if someone had told us beforehand that there
could be issues.
I don’t know the exact behavior of today’s browsers when waiting for a
timeout of the OCSP Server, but I would strongly recommend using a
default port if possible in any way.
Best regards
Ramin
Eddy Nigg
> So what it’s required to use in the AIA extensión is an URI, what if
> instead of using http/s someone decide to use SMTP, LDAP, SOAP, etc,
> will mozilla implement all posible transport protocols?
>
Maybe, you can always suggest and submit patches. Any contribution is
welcome.
> I’ve just test it and it works fine, the only think is that I had to
> include the Izenpe hierarchy into Mozilla manually and then test it.
>
It works now thanks to Kathleen's testing and insistence, it didn't
until very recently. You can see all the glory at
https://bugzilla.mozilla.org/show_bug.cgi?id=361957 and
https://bugzilla.mozilla.org/show_bug.cgi?id=554598
> Fully agree, I would like also to SUGGEST this change rather than to
> impose.
Well, I do the suggesting and recommending. Kathleen does the imposing
if needed :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Matt McCutchen
> 1) OCSP Responder (http://ocsp.izenpe.com:8097)
> A concern was raised that port 8097 is an unusual port number; ports 80
> and 443 are considered usual ports for http type traffic. The concern is
> that port 8097 might not work with existing browsers or might be blocked
> by most networks.
>
> Izenpe’s representative responded that they have not run into any
> problems with their current port number convention.
FWIW, I remember once using public Wi-Fi in a library in Delaware
where ports 80 and 443 were open but several others that I tried were
blocked: 110 (POP3) and 22 (ssh) IIRC. Of course, I didn't test 8097
specifically. So there are probably some networks from which clients
would be unable to use the Izenpe OCSP server, though perhaps not
many.
--
Matt
Kathleen Wilson
> On Thu, Jun 17, 2010 at 7:56 AM, etowers<emanuel...@gmail.com> wrote:
>> Since there are not specific written specifications the choose of the
>> “unusual port” 8097 is as fanciful as the choose of the “usual ports”
>> 80/443. To argue that firewalls usually block non usual ports is a
>> weak and not proved argument, much more when Izenpe has affirmed they
>> have not found any problem during the last eight years when using non
>
> Ok. So will your company commit, in a signed and notarized statement
> that if it is found to be a problem you will move to ports 80/443
> immediately and re-issue all the existing certificates immediately?
> Will you place this as an official clause in your CPS?
Mozilla is not requiring this.
There are many good reasons listed in this discussion about why it is
recommended that Izenpe switch to using a standard port. However, the
non-standard port does not go against Mozilla's CA Certificate policies.
Mozilla does not view the use of the non-standard port for OCSP as a
reason to not approve this root for inclusion.
However, Mozilla does strongly recommend that Izenpe move to using a
standard port for OCSP. To my knowledge, none of the CAs with roots that
are currently included NSS use non-standard ports in their AIA OCSP URI.
If we find at some point in the future that the non-standard port causes
a significant portion of our user base not to be able to make OCSP
requests, then that will be grounds to suspend trust for the root.
Kathleen
Kathleen Wilson
> As Kathleen has suggested, there are 2 items opened, OCSP (although
> this one has been set as action:none) and email.
>
> 1.- OCSP
>
Mozilla is not requiring specific changes to Izenpe's OCSP at this time.
However, Mozilla strongly recommends that Izenpe move to using a
standard port for OCSP. To my knowledge, none of the CAs with roots that
are currently included NSS use non-standard ports in their AIA OCSP URI.
If we find at some point in the future that the non-standard port causes
a significant portion of our user base not to be able to make OCSP
requests, then that will be grounds to suspend trust for the root.
>
> 2.- email trust bit
>
It sounds like Izenpe would still like to proceed with enabling the
email (S/MIME) trust bit for this root.
> - We have some other profiles that include the emailProtection and
> smartCardLogon flags into the extendedKeyUsage. These are the
> corporate ones (public and privates) and the ones for the civil
> servants. Those certificates are issued as mentioned above to the
> public employees or civil servants of the government, there´s a
> registration procedure that require a positive identification of all
> the data contained in the certificate. As mentioned, of course, we
> take all the measures to check everything. Besides, the employee has
> to sign a contract for which he/she is liable for the identity
> information provided. Again, following the current legislation. Also,
The concern is not about the procedures for verifying the identity of
the certificate subscriber. Information about the steps taken to confirm
the identity of the certificate subscriber is provided in section 3 of
Izenpe's Certificate Specific documents.
The concern is about the lack information in a public-facing, audited
document describing steps that must be taken to verify that the
certificate subscriber owns/controls the email address to be included in
the certificate. This is required by section 7 of the Mozilla CA
Certificate Policy. Most CA's satisfy this requirement by using a
challenge-response test.
> during the registration procedure, it´s verified all the identity
> informaion provided by the public employee, including the email that
> belong to the organization. These procedures have been reviewed by the
> auditors in the assesments, if you trust such audits.
Who verifies that the email address belongs to the organization?
What are the steps that are taken to perform that verification?
Can this be documented in a public-facing and audited document?
> - There are some other certificate profiles that use the
> emailProtection, and those are "technical ones", like application,
> seal, site. These certifcates are quite similar to SSL web server
> certificates and they follow the specific spanish legislation (law
> 11/2007 for the electronic public administration). These kind of
> certificates are used to digitally sign on behalf of the "public
> administration" not for a person. The procedure to issue these
> certificates is the same in which we check that the email address
> provided by the institution belong to its domain and it exists.
Who checks that the email address provided by the institution belongs to
the institution's domain?
What are the steps that are taken to perform the verification?
Can this be documented in a public-facing and audited document?
Kathleen
Robin Alden
What is your rationale for this statement:
"If we find at some point in the future that the non-standard port
causes a significant portion of our user base not to be able to
make OCSP requests, then that will be grounds to suspend trust for
Is it the case that you would usually only suspend trust for a
root where your users' security is threatened?
Is it the case that the lack of a "GOOD" OCSP response will
prevent trust being placed in a certificate?
I understand your recommendation, but don't understand how a
partially available OCSP responder threatens your users' security.
Regards
Robin Alden
Comodo
> -----Original Message-----
> From: dev-security-policy-
> bounces+robin=comod...@lists.mozilla.org [mailto:dev-security-
> policy-bounces+robin=comod...@lists.mozilla.org] On Behalf Of
> Kathleen Wilson
> Sent: 18 June 2010 18:27
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Izenpe Root Inclusion Request
>
> On 6/18/10 5:17 AM, Iñigo wrote:
> > As Kathleen has suggested, there are 2 items opened, OCSP
> (although
> > this one has been set as action:none) and email.
> >
> > 1.- OCSP
> >
>
> Mozilla is not requiring specific changes to Izenpe's OCSP at
> this time.
>
> However, Mozilla strongly recommends that Izenpe move to using a
> standard port for OCSP. To my knowledge, none of the CAs with
> roots that
> are currently included NSS use non-standard ports in their AIA
> OCSP URI.
> If we find at some point in the future that the non-standard
> port causes
> a significant portion of our user base not to be able to make
> OCSP
> requests, then that will be grounds to suspend trust for the
> root.
>
> >
> > 2.- email trust bit
> >
>
> It sounds like Izenpe would still like to proceed with enabling
> the
> email (S/MIME) trust bit for this root.
>
> > - We have some other profiles that include the emailProtection
> and
> > smartCardLogon flags into the extendedKeyUsage. These are the
> > corporate ones (public and privates) and the ones for the
> civil
> > servants. Those certificates are issued as mentioned above to
> the
> > public employees or civil servants of the government, there´s
> a
> > registration procedure that require a positive identification
> of all
> > the data contained in the certificate. As mentioned, of
> course, we
> > take all the measures to check everything. Besides, the
> employee has
> > to sign a contract for which he/she is liable for the identity
> > information provided. Again, following the current
> legislation. Also,
>
>
> The concern is not about the procedures for verifying the
> identity of
> the certificate subscriber. Information about the steps taken to
> confirm
> the identity of the certificate subscriber is provided in
> section 3 of
> Izenpe's Certificate Specific documents.
>
> The concern is about the lack information in a public-facing,
> audited
> document describing steps that must be taken to verify that the
> certificate subscriber owns/controls the email address to be
> included in
> the certificate. This is required by section 7 of the Mozilla CA
> Certificate Policy. Most CA's satisfy this requirement by using
> a
> challenge-response test.
>
> > during the registration procedure, it´s verified all the
> identity
> > informaion provided by the public employee, including the
> email that
> > belong to the organization. These procedures have been
> reviewed by the
> > auditors in the assesments, if you trust such audits.
>
> Who verifies that the email address belongs to the organization?
> What are the steps that are taken to perform that verification?
> Can this be documented in a public-facing and audited document?
>
>
> > - There are some other certificate profiles that use the
> > emailProtection, and those are "technical ones", like
> application,
> > seal, site. These certifcates are quite similar to SSL web
> server
> > certificates and they follow the specific spanish legislation
> (law
> > 11/2007 for the electronic public administration). These kind
> of
> > certificates are used to digitally sign on behalf of the
> "public
> > administration" not for a person. The procedure to issue these
> > certificates is the same in which we check that the email
> address
> > provided by the institution belong to its domain and it
> exists.
>
> Who checks that the email address provided by the institution
> belongs to
> the institution's domain?
> What are the steps that are taken to perform the verification?
> Can this be documented in a public-facing and audited document?
>
> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Kathleen Wilson
> Kathleen,
> What is your rationale for this statement:
> "If we find at some point in the future that the non-standard port
> causes a significant portion of our user base not to be able to
> make OCSP requests, then that will be grounds to suspend trust for
> the root."?
>
> Is it the case that you would usually only suspend trust for a
> root where your users' security is threatened?
>
> Is it the case that the lack of a "GOOD" OCSP response will
> prevent trust being placed in a certificate?
>
> I understand your recommendation, but don't understand how a
> partially available OCSP responder threatens your users' security.
>
> Regards
> Robin Alden
> Comodo
>
In more recent versions of Firefox, OCSP is enforced by default. We
don't want users to be getting errors accessing websites because of the
way an OCSP service is set up.
If we find that users are getting errors accessing websites because of
the way an OCSP service is set up, then we reserve the right to turn off
the trust bits for that root (effectively disabling that root). As
you've seen in the past we try to work with the CA to get them to fix
their OCSP service before going the route of disabling the root.
Kathleen
Eddy Nigg
> Is it the case that the lack of a "GOOD" OCSP response will
> prevent trust being placed in a certificate?
>
> I understand your recommendation, but don't understand how a
> partially available OCSP responder threatens your users' security.
>
Well, just consider a certificate would have been mistakenly issued to
mozilla.com and the certificate would be used to attack users by having
them download Firefox browsers or addons with built-in key loggers. Now
just imagine the OCSP responder doesn't work correctly.
Robin Alden
not security, but stopping users from seeing error messages.
Regards
Robin
> -----Original Message-----
> From: dev-security-policy-bounces+robin=comod...@lists.mozilla.org
> [mailto:dev-security-policy-bounces+robin=comod...@lists.mozilla.org]
> On Behalf Of Kathleen Wilson
> Sent: 18 June 2010 19:03
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Izenpe Root Inclusion Request
>
> On 6/18/10 10:39 AM, Robin Alden wrote:
> > Kathleen,
> > What is your rationale for this statement:
> > "If we find at some point in the future that the non-standard port
> > causes a significant portion of our user base not to be able to
> > make OCSP requests, then that will be grounds to suspend trust for
> > the root."?
> >
> > Is it the case that you would usually only suspend trust for a
> > root where your users' security is threatened?
> >
> > Is it the case that the lack of a "GOOD" OCSP response will
> > prevent trust being placed in a certificate?
> >
> > I understand your recommendation, but don't understand how a
> > partially available OCSP responder threatens your users' security.
> >
> > Regards
> > Robin Alden
> > Comodo
> >
>
> In more recent versions of Firefox, OCSP is enforced by default. We
> don't want users to be getting errors accessing websites because of the
> way an OCSP service is set up.
>
> If we find that users are getting errors accessing websites because of
> the way an OCSP service is set up, then we reserve the right to turn
> off
> the trust bits for that root (effectively disabling that root). As
> you've seen in the past we try to work with the CA to get them to fix
> their OCSP service before going the route of disabling the root.
>
Robin Alden
If the browser cannot fetch an OCSP response for the certificate then it
will not trust the certificate.
I don't see how that relates to mis-issued or fraudulently applied-for
certificates - or to key-loggers.
Robin
> -----Original Message-----
> From: dev-security-policy-bounces+robin=comod...@lists.mozilla.org
> [mailto:dev-security-policy-bounces+robin=comod...@lists.mozilla.org]
> On Behalf Of Eddy Nigg
> Sent: 18 June 2010 19:15
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Izenpe Root Inclusion Request
>
> On 06/18/2010 08:39 PM, From Robin Alden:
> > Is it the case that the lack of a "GOOD" OCSP response will
> > prevent trust being placed in a certificate?
> >
> > I understand your recommendation, but don't understand how a
> > partially available OCSP responder threatens your users' security.
> >
>
> Well, just consider a certificate would have been mistakenly issued to
> mozilla.com and the certificate would be used to attack users by having
> them download Firefox browsers or addons with built-in key loggers. Now
> just imagine the OCSP responder doesn't work correctly.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>
Eddy Nigg
> Eddy, you miss the point with your usual eloquence.
>
> If the browser cannot fetch an OCSP response for the certificate then it
> will not trust the certificate.
>
Right - but this is not the case currently, the browser proceeds in that
case. Only if a successful response was received by the responder will
the browser act accordingly (e.g. report revocation in case the
certificate is revoked).
> I don't see how that relates to mis-issued or fraudulently applied-for
> certificates - or to key-loggers.
>
No? If the OCSP responder doesn't work and the browser proceeds
nevertheless, doesn't that impact the users security under the
circumstances of an attack?
Eddy Nigg
> In more recent versions of Firefox, OCSP is enforced by default. We
> don't want users to be getting errors accessing websites because of
> the way an OCSP service is set up.
>
Kathleen, which version exactly has OCSP set to hard fail instead of a
soft fail by default? I understood that this was planned for a future
version, I wasn't aware that the future is already here. :-)
Kathleen Wilson
> On 06/18/2010 09:02 PM, From Kathleen Wilson:
>> In more recent versions of Firefox, OCSP is enforced by default. We
>> don't want users to be getting errors accessing websites because of
>> the way an OCSP service is set up.
>>
>
> Kathleen, which version exactly has OCSP set to hard fail instead of a
> soft fail by default? I understood that this was planned for a future
> version, I wasn't aware that the future is already here. :-)
>
Well, it looks like I misunderstood the status of OCSP in Firefox.
Here's what mozillaZine says.
http://kb.mozillazine.org/OCSP_error_when_accessing_secure_sites
--
In Firefox 3 and above, OCSP is enabled by default; however, errors when
an OCSP server connection fails are also suppressed by default ("Tools
-> Options -> Advanced -> Encryption -> Validation -> When an OCSP
server connection fails, treat the certificate as invalid" is unchecked,
by default).
--
I guess that explains why I regularly run into the problem of OCSP not
working for CA root inclusion/change requests.
Kathleen
Eddy Nigg
>
> I guess that explains why I regularly run into the problem of OCSP not
> working for CA root inclusion/change requests.
>
If you use Firefox to check if an OCSP is working correctly you
obviously have to set OCSP checking to hard fail, otherwise it will
simply ignore a failed response. You are doing that correctly, because
once it will be set to hard fail in the future, many CAs which have been
recently approved and had non-compliant responders would have all been
unusable.
This however also means that for those with non-compliant OCSP
responders, NO revocation status checking will be done at the moment.
This is quite significant - it amounts to approximately 30% or more of
all relying parties of that CA and would be vulnerable to certain attacks.
More than that, today 100% of all Mozilla Firefox users are vulnerable
to some extend. An attacker can simply block access to the OCSP
responder and an attack with a revoked certificate would succeed.
Robin Alden
> On 06/19/2010 02:00 AM, From Kathleen Wilson:
> >
> not
> > working for CA root inclusion/change requests.
> >
>
> obviously have to set OCSP checking to hard fail, otherwise it will
> simply ignore a failed response. You are doing that correctly, because
> once it will be set to hard fail in the future, many CAs which have
> been
> recently approved and had non-compliant responders would have all been
> unusable.
>
> This however also means that for those with non-compliant OCSP
> responders, NO revocation status checking will be done at the moment.
> This is quite significant - it amounts to approximately 30% or more of
> all relying parties of that CA and would be vulnerable to certain
> attacks.
>
> More than that, today 100% of all Mozilla Firefox users are vulnerable
> to some extend. An attacker can simply block access to the OCSP
> responder and an attack with a revoked certificate would succeed.
>
[Robin Alden]
I agree. Treating a failed attempt to check revocation the same way you
treat a successful revocation check is not a feature, it's a vulnerability.
Regards
Robin
Iñigo
Hi again,
well, we have decided the following:
1.- OCSP: We understand the suggestion, and we´ll see what we can do.
The change will take time, and will be applicable to issuance of new
certificates.
2.- email trust bit: We have decided to not enable the email trust bit
at this time.
Regards
Jean-Marc Desperrier
> In Firefox 3 and above, OCSP is enabled by default; however, errors when
> an OCSP server connection fails are also suppressed by default ("Tools
> -> Options -> Advanced -> Encryption -> Validation -> When an OCSP
> server connection fails, treat the certificate as invalid" is unchecked,
> by default).
For EV certificat, OCSP is mandatory.
Wouldn't the proper way be to only display as EV the certficates that it
has been possible to verify with OCSP ?
Erwann Abalea
In message <mailman.3296.1276987075....@lists.mozilla.org>
by Eddy Nigg dated 20/06/2010:
-----
Currently EV status is not shown in case OCSP fails, but shows the regular SSL UI.
-----
--
Erwann.
Kathleen Wilson
Is OCSP mandatory for EV certs?
Kathleen
Kathleen Wilson
> Izenpe has applied to add the SHA256 �Izenpe.com� root certificate, and
> to enable all three trust bits. The request is to also enable EV.
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=361957
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Izenpe
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=444730
>
Thanks to all of you who have contributed to this discussion. Your input
is greatly appreciated.
Here is a summary of the main topics of this discussion.
1) OCSP Responder (http://ocsp.izenpe.com:8097)
Many good reasons were listed in this discussion about why it is
recommended that Izenpe switch to using a standard port.
Izenpe Response: We understand the suggestion, and we�ll see what we can
do. The change will take time, and will be applicable to issuance of new
certificates.
ACTION: I encourage Izenpe to follow through on this, but I don't plan
to track this action item in the bug.
2) ETSI certification
Clarification was provided as requested.
ACTION: None
3) Email Address Verification
Izenpe Response: We have decided to not enable the email trust bit
at this time.
ACTION: None
I propose to close this discussion and move forward with recommending
approval for the inclusion of the SHA256 �Izenpe.com� root certificate,
and to enable the websites and code signing trust bits, and to enable EV.
Kathleen
Eddy Nigg
>
> Is OCSP mandatory for EV certs?
>
According to 11.1.1:
/It is strongly RECOMMENDED that all CAs support OCSP when a majority of
deployed Web servers support the
TLS 1.0 extension in accordance to RFC 3546, to return “stapled” OCSP
responses to EV-enabled applications.
CAs MUST support an OCSP capability for Subscriber Certificates that are
issued after Dec 31, 2010./
Since Mozilla Firefox doesn't have other revocation capabilities without
the intervention by the user, it's more than reasonable that CAs
admitted must have OCSP responders that work with this product.
Kathleen Wilson
> On 6/3/10 11:29 AM, Kathleen Wilson wrote:
>> to enable all three trust bits. The request is to also enable EV.
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=361957
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#Izenpe
>>
>> Summary of Information Gathered and Verified:
>> https://bugzilla.mozilla.org/attachment.cgi?id=444730
>>
>
Thank you to those of you who have reviewed this request and provided
your feedback in this discussion. Your participation in this process is
greatly appreciated.
The results of this discussion are as follows.
Izenpe has decided to proceed with the enablement of the websites and
code signing trust bits. The email trust bit will not be enabled at this
time.
The CA:Recommended_Practices wiki page has been updated to add a section
about OCSP:
https://wiki.mozilla.org/CA:Recommended_Practices#OCSP
The Izenpe representative has stated that they understand the
recommendations and plan to follow up on them in regards to issuance of
new certificates.
I will post my recommendation for approval of this root inclusion
request in the bug.
This concludes the public discussion about IZENPE’s request to add one
new root CA certificate to the Mozilla root store, as documented in the
following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=361957
All follow-ups on this request should be posted directly in the bug.
Thanks,
Kathleen
Eddy Nigg
> The CA:Recommended_Practices wiki page has been updated to add a
> section about OCSP:
> https://wiki.mozilla.org/CA:Recommended_Practices#OCSP
>
> The Izenpe representative has stated that they understand the
> recommendations and plan to follow up on them in regards to issuance
> of new certificates.
>
> I will post my recommendation for approval of this root inclusion
> request in the bug.
>
Kathleen, please hold the inclusion of this root until we can determine
how issue https://bugzilla.mozilla.org/show_bug.cgi?id=578499#c6 affects
the overall performance and already widely discussed issues regarding
their OCSP responders.
I'm really concerned!
Kurt Seifried
which I can't access from a few places (due to non standard HTTP port).
Also (frighteningly) chrome trusts this cert.
-Kurt
Kathleen Wilson
to enable all three trust bits. The request is to also enable EV.
Izenpe is a public company belonging to the Basque Country Government so
the general nature is government. The primary geographical area is the
Basque Country but all of their certificates are recognized, accepted,
and validated by all of the PKIs in Spain, so the geographical area
relates to Spain.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=361957
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Izenpe
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=444730
Noteworthy points:
* This root has five internally-operated subordinate CAs. One sub-CA
issues EV SSL certs. Two of the sub-CAs are for Qualified certificates,
one for Public Administration, and one for Citizens and Entities. There
are also two sub-CAs for non-Qualified certificates, one for Public
Administration and one for Citizens and Entities, which issue SSL
Server, Email, and Code Signing certs.
** A CA Hierarchy diagram is available here:
https://servicios.izenpe.com/jsp/descarga_ca/s27descarga_ca_c.jsp
* The CPS is available in Spanish, Basque, and English at
http://www.izenpe.com/cps. However the main documents of interest are
the “Documentación Específica” for each type of certificate, and all of
these are in Spanish. Translations of some sections of these documents
are provided in the Information Gathering document.
Certificate Specific Documentation:
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/solicitar_certificado_digital.html
* The request is to enable all three trust bits.
* Procedures for Secure Server Certificates:
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentaci%C3%B3n%20espec%C3%ADfica%20SSL%20castellano_nov09.pdf
** Section 3.2 describes the procedures for identifying the certificate
applicant and organization.
** Section 3.3: IZENPE requires that documentation has been delivered
and validated before the certificate may be issued. This includes
checking the user identity using a notary and public records. Izenpe
uses whois to verify that the applicant has the right to use the domain
or subdomain.
** Here are snippets of the translations of section 3.3: With respect to
domains and Internet addresses, only consult IZENPE registrars appointed
by ICANN / IANA for domain names and addresses associated with the
certificate.
*** It verifies that the domain does not appear in the listings as at
risk (see Chapter 3.8).
*** Constitution, date, name, NIF that we will make the constitution of
the body applicant, verified by consulting the register where required
establish its existence and commonality with the documentation provided
by the applicant.
*** Search the whois database, verify that the domain is registered,
consulting valid records. Be attached copy of the whois query the
minutes of validation.
*** There is a list of registrars supported by domain type
(http://www.iana.org/domains/root/db/) that are either generic (gTLD's)
or country (country-code, ccTLDs) that indicates which is the official
registrar for each delegate type of domain. Specifically, you can check
the whois for the more usual domains .com .net .org .info --
http://www.networksolutions.com/whois/index.jsp. Domains .es --
http://www.nic.es
** How the owner (registrant) agrees with the applicant organization. In
case of a mismatch, the applicant must provide documentation to
establish the right of use by the owner. IZENPE contact the owner listed
in the whois to verify that the applicant has the right to use the
domain or subdomain.
* Procedures for Corporate Certificates:
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentaci%C3%B3n%20Espec%C3%ADfica%20Corporativo%20reconocido%20castellano_nov09.pdf
**Section 2 describes Identification Obligations and Section 3 describes
Identification and Authentication procedures.
** The email address is an optional field. The organization requesting
that the email address be included in certs for their employees is
responsible for verifying the ownership/control of the email address.
Izenpe signs a contract with the correspondent department or public
society and they identify their own employees to issue certificates to
and provide the information to Izenpe.
* Procedures for Code Signing Certificates:
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Procedimiento_Firma_C%C3%B3digo_castellano_06-03-24.pdf
** Here are snippets from Section 1.2, Accreditation of Identity of
Applicant: The applicant must prove his identity, and where applicable,
the constitution of the entity he represents, providing the necessary
documentation.
*** The applicant must provide an original or certified true copy of the
following documentation: Identification Elements, ID card or passport,
in case of national citizen. In case a foreign national: Member of the
European Union or of States party to the EEA European, an NIE will be
payable together with an identity in force for the purpose of
verification of their identity. With regard to non-EU citizens, the card
will be required residence. …
*** It will be necessary to obtain supporting evidence for the existence
of the entity and to the powers of representation of the one acting on
its behalf, provided that the actions were governed by rule.
* The request is to also enable EV.
** EV Policy OID: 1.3.6.1.4.1.14777.6.1.1
** Procedures for EV SSL Secure Server Certificates:
http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentaci%C3%B3n%20espec%C3%ADfica%20%20SSL%20EV%20castellano_nov09.pdf
** Here are snippets from translation of Section 3.1.3 Validation:
*** The documentation relating to the user organization will be verified
by the Advisory Legal IZENPE.
*** The Technical Department will review and validate all information
subsequently provided by the Legal Area and finally determined by
signature that the documentation is correct
*** The technical application is reviewed and validated by the Technical
Area IZENPE. The Legal and Technical Department analyze the
documentation regarding the registration of each entity in the
appropriate register, the register may contact via other means.
*** With respect to domains and Internet addresses, only consult IZENPE
registrars appointed by ICANN / IANA for domain names and
addressesassociated with the certificate.
*** The Legal and Technical Area Contact verify the documentation
provided by the firm:
*** It verifies that domain does not appear in the listings as at risk
(see Chapter 3.8).
*** Address: will check if registration data are consistent with the
documentation provided. In the event that both directions are not
coincident IZENPE verify that the address on the application refers to a
location in which the entity applicant operates stably. This checking
may be undertaken through signed statement or proof of payment of taxes.
*** Phone. IZENPE must verify that the phone (must be a landline, not
cell) belongs to the applicant entity (consulting the yellow pages and
registration subsequent verification by call).
*** Evidence of activity of organization: Certificate issued by an
entity bank certifying the existence of an account on behalf of the
entity applicant, proof of payment of local taxes. Requirement does not
apply in the case of Public Administration.
*** On the Internet domain (not applicable to internal domains):
*** Search the whois database, verify that the domain is registered,
consulting valid records. Be attached copy of the whois query the
minutes of validation.
*** There is a list of registrars supported by domain
type(http://www.iana.org/domains/root/db/) that are either generic
(gTLD's) or country (country-code, ccTLDs) that indicates which is the
official registrar for each delegate type of domain. Specifically, you
can check the whois for the most common in domains .com .net .org .info
-- http://www.networksolutions.com/whois/index.jsp. Domains .es --
http://www.nic.es
*** How the owner (registrant) agrees with the applicant organization.
In case of a mismatch, the applicant must provide documentation
supporting the right of use by the owner. IZENPE contact the owner
listed whois in verifying that the applicant has the right to use the
domain or subdomain.
* Test Website: https://www.it-txartela.net
* CRLs have a NextUpdate of 10 days and are refreshed every 1 day
** SSL EV certs: http://crl.izenpe.com/cgi-bin/crlsslev
** Citizen and Entity qualified certs:
http://crl.izenpe.com/cgi-bin/crl2
** Citizen and Entity non-qualified certs:
http://crl.izenpe.com/cgi-bin/crlscinr2
** Public Administration qualified certs:
http://crl.izenpe.com/cgi-bin/crlscar2
** Public Administration non-qualified certs:
http://crl.izenpe.com/cgi-bin/crlinterna2
* OCSP: http://ocsp.izenpe.com:8097
* Audit
** The WebTrust EV audit was performed by KPMG:
https://cert.webtrust.org/SealFile?seal=1017&file=pdf
** An ETSI 101 456 audit is also performed by BSI Management Systems
B.V. The ETSI certificate can be viewed by going to the BSI website,
http://www.bsi-global.com/ClientDirectory, and entering Izenpe for the
Certificate & Client Directory Search.
This begins a 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
Eddy Nigg
On 06/03/2010 09:29 PM, From Kathleen Wilson:
>
> * OCSP: http://ocsp.izenpe.com:8097
Does this responder work for all issuers under the Izenpe root? Why is
such an unusual port number used? It's common practice, specially with
corporate networks, that unusual ports are prevented from being accessed.
When I access this URL I receive an HTML page "- Welcome to KeyOne VA
-", this doesn't appear to be an OCSP response.
>
> * Audit
> ** The WebTrust EV audit was performed by KPMG:
> https://cert.webtrust.org/SealFile?seal=1017&file=pdf
> ** An ETSI 101 456 audit is also performed by BSI Management Systems
> B.V. The ETSI certificate can be viewed by going to the BSI website,
> http://www.bsi-global.com/ClientDirectory, and entering Izenpe for the
> Certificate & Client Directory Search.
In the registered scope of the ETSI document, what does "the services
marked (*) are provided with the support of third-party service
providers" exactly mean? It appears that almost all "services" are
affected?
Iñigo
Hi Eddy,
these are the answers.
According to Mozilla recommendations and as you can see in the
bugzilla, we had to create a new VA for the CA issuing EV certs, this
one is using the port 8097 just to follow the numbering we were using.
We have another VA using port 8094, etc. So we considered that 8097 is
correct and without any problem. What do you mean with unusual port? I
don´t think is unusual, maybe you don´t use it but does not mean is
unusual.
About the message, it´s just for checking the VA is up and running,
that´s it. It´s a quick method to check the VA and it has been agreed
and applauded by some different browsers, software providers, CAs, etc
as a best practice. This is not related to an OCSP respond, it´s a
totally different thing. AS said, it´s just a message to check the
status of the VA, if you don´t see that message, that means that VA is
down.
And about the ETSI certification, the * means that those services are
opperated by a thir party. In our case, as a government CA, the main
stakeholder is the government and by law all of our hardware and
software are under the government premises and managed by the
government. The PKI services are managed by Izenpe.
Regards
Kurt Seifried
>
> According to Mozilla recommendations and as you can see in the
> bugzilla, we had to create a new VA for the CA issuing EV certs, this
> one is using the port 8097 just to follow the numbering we were using.
> We have another VA using port 8094, etc. So we considered that 8097 is
> correct and without any problem. What do you mean with unusual port? I
> don´t think is unusual, maybe you don´t use it but does not mean is
> unusual.
A more usual port for HTTP type traffic would be 80 or 443 (which will
definitely not be blocked), also some web browsers like Safari
blacklist requests to unusual ports, I'd be curious to know if your
choices are compatible with this.
Have you confirmed that these ports will work with existing browsers,
and that they are widely available and not blocked by most networks?
In other words using 80/443 is probably safer.
-Kurt
Iñigo Barreira
We haven´t had any problem with any browser and none has even mentioned why
we use that port. Of course, ports 80/443 are commonly used and we also used
them, but for different services.
In the email I say that we belong to the Government and we´re using the same
infraestructure, that means, netwroking, internet connection and so on than
anyone in the government, and those ports where in use for other services,
situations, etc so they reserved a number of them for us in their
infraestructure to use, and that´s what we do.
We don´t have any problem with Safari, we are even in their root program
Regards
2010/6/9 Kurt Seifried <ku...@seifried.org>
Kurt Seifried
> we use that port. Of course, ports 80/443 are commonly used and we also used
> them, but for different services.
> In the email I say that we belong to the Government and we´re using the same
> infraestructure, that means, netwroking, internet connection and so on than
> anyone in the government, and those ports where in use for other services,
But the problem is your certificates are trusted by Mozilla, not just
people in your government. I need to be able to check the OCSP ports.
As does everyone else using Mozilla products.
-Kurt
Iñigo Barreira
2010/6/9 Kurt Seifried <ku...@seifried.org>
Eddy Nigg
> that the email address be included in certs for their employees is
> responsible for verifying the ownership/control of the email address.
> Izenpe signs a contract with the correspondent department or public
> society and they identify their own employees to issue certificates to
> and provide the information to Izenpe.
I've read the explanation at the bug and it appears that this doesn't
satisfy the Mozilla CA Policy which states:
/for a certificate to be used for digitally signing and/or encrypting
email messages, the CA takes reasonable measures to verify that the
entity submitting the request controls the email account associated with
the email address referenced in the certificate /or/ has been authorized
by the email account holder to act on the account holder's behalf;/
The current implementation is basically self-signed assertion. Also I
understand the difficulty of verifying thousands of email addresses,
other CAs are subject to the same requirement I believe. Perhaps the
email trust bit might have to be reconsidered or either policies modified.
All the rest looks good to me as far as I can see.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Iñigo
Hi Eddy,
I didn´t probably explain myself correctly. It´s not a self-signed
assertion. Of course we take reasonable measures to check everything
because for example, we, in the government, share the same domain and
email server so we can (and do) all the checks necessary to verifu the
information. Furthermore, we sign a contract agreement with the
customer requesting all the information besides the request form and
so on. We set up all the conditions in that contract in order to
verify, validate, etc all the information and with all the legal
requisites by law, for example, the data protection law, etc.
Of course, as you mention, is very complicated when you try to do for
all the civil servants and government employees, there are thousands
of data to check and verify.
Regards
Kathleen Wilson
> to enable all three trust bits. The request is to also enable EV.
> http://www.izenpe.com/s15-12020/es/contenidos/informacion/solicitar_certificado_digital/es_solicita/adjuntos/Documentaci%C3%B3n%20Espec%C3%ADfica%20Corporativo%20reconocido%20castellano_nov09.pdf
>
> **Section 2 describes Identification Obligations and Section 3 describes
> Identification and Authentication procedures.
> ** The email address is an optional field. The organization requesting
> that the email address be included in certs for their employees is
> responsible for verifying the ownership/control of the email address.
> Izenpe signs a contract with the correspondent department or public
> society and they identify their own employees to issue certificates to
> and provide the information to Izenpe.
Thank you Eddy and Kurt for reviewing and commenting on this request.
Further reviews and comments are still welcome and would be appreciated.
Here is a summary of the discussion about this request from Izenpe to
add a root certificate, enable all three trust bits, and enable EV.
1) OCSP Responder (http://ocsp.izenpe.com:8097)
A concern was raised that port 8097 is an unusual port number; ports 80
and 443 are considered usual ports for http type traffic. The concern is
that port 8097 might not work with existing browsers or might be blocked
by most networks.
Izenpe’s representative responded that they have not run into any
problems with their current port number convention.
I am able to open the test website with OCSP enforced in my Firefox
browser, so I don’t think there is an action item here.
ACTION: None
2) ETSI certification
Clarification was requested and provided about the note in the ETSI
certificate about services that are operated by third parties. Izenpe’s
representative clarified that as a government CA, the main stakeholder
is the government and by law all of their hardware and software are
under the government premises and managed by the government. The PKI
services are managed by Izenpe.
ACTION: None
3) Email Address Verification
A concern was raised that there is not sufficient documentation in a
public-facing and audited document to meet the requirements of section 7
of the Mozilla CA Certificate Policy
(http://www.mozilla.org/projects/security/certs/policy/) in regards to
verifying that the certificate subscriber owns/controls the email
address to be included in the certificate.
I would like to ask Izenpe to re-consider if it is necessary to enable
the email trust bit for this root certificate in NSS. If yes, then
please describe the types of Mozilla users that are likely to encounter
this root certificate and need to have the email trust bit enabled in NSS.
ACTION: To be determined. If email trust bit does not need to be
enabled, then no action. If email trust bit does need to be enabled,
then more clarification will be needed, and possibly an update to the
appropriate public-facing and audited document(s).
Kathleen
Kurt Seifried
> A concern was raised that port 8097 is an unusual port number; ports 80 and
> 443 are considered usual ports for http type traffic. The concern is that
> port 8097 might not work with existing browsers or might be blocked by most
> networks.
>
> Izenpe’s representative responded that they have not run into any problems
> with their current port number convention.
>
> I am able to open the test website with OCSP enforced in my Firefox browser,
> so I don’t think there is an action item here.
>
> ACTION: None
I thought about this a bit and realize I have 3 main concerns:
1) more and more ISP's are engaging in traffic shaping and many
corporate/etc. networks are doing deep traffic inspection and blocking
abnormal traffic (this would fit the profile, strange port, with HTTP
traffic, my first thought would be bot net C&C or something). Better
to err on the side of caution and use a standard port I think.
2) it's not a problem until it becomes a problem, and then it cannot
be fixed. All the existing certificates will point to an unreachable
(for some) server. Better to err on the side of caution and use a
standard port I think. What will they do to address this issue in
future, re-issue all the certificates with a new OCSP point? I doubt
this. Which means a lot of users are put at significant potential
risk.
3) Autonomy and control, if I read the original email correctly it
sounds like the OCSP server is running on government infrastructure
(network and server) that the CA does not control. This is based on
the fact they need to use a non-standard port because ports 80/443 are
already in use by a web server. If a CA does not control their own
infrastructure or is incapable of the technical challenges (i.e.
running two separate services both on port 80/443 because they don't
have enough hardware/IP's/load balancing front end that can redirect
traffic, etc.) I would not trust them to act as a CA with respect to
key security, operational security, etc.
I think that combined these represent a significant set of problems
(especially #2, aka the "we can't fix it if it breaks" issue). I would
ask that this question be re-opened and corrective action be taken
(i.e. running the OCSP on a standard port). If the CA is
unable/incapable of doing this due to technical/operational reasons I
would really have to call their competency into question.
-Kurt
Kathleen Wilson
>> 1) OCSP Responder (http://ocsp.izenpe.com:8097)
>> A concern was raised that port 8097 is an unusual port number; ports 80 and
>> 443 are considered usual ports for http type traffic. The concern is that
>> port 8097 might not work with existing browsers or might be blocked by most
>> networks.
>>
>> with their current port number convention.
>>
>> I am able to open the test website with OCSP enforced in my Firefox browser,
>>
>> ACTION: None
>
> I thought about this a bit and realize I have 3 main concerns:
>
> 1) more and more ISP's are engaging in traffic shaping and many
> corporate/etc. networks are doing deep traffic inspection and blocking
> abnormal traffic (this would fit the profile, strange port, with HTTP
> traffic, my first thought would be bot net C&C or something). Better
> to err on the side of caution and use a standard port I think.
>
> 2) it's not a problem until it becomes a problem, and then it cannot
> be fixed. All the existing certificates will point to an unreachable
> (for some) server. Better to err on the side of caution and use a
> standard port I think. What will they do to address this issue in
> future, re-issue all the certificates with a new OCSP point? I doubt
> this. Which means a lot of users are put at significant potential
> risk.
>
> 3) Autonomy and control, if I read the original email correctly it
> sounds like the OCSP server is running on government infrastructure
> (network and server) that the CA does not control. This is based on
> the fact they need to use a non-standard port because ports 80/443 are
> already in use by a web server. If a CA does not control their own
> infrastructure or is incapable of the technical challenges (i.e.
> running two separate services both on port 80/443 because they don't
> have enough hardware/IP's/load balancing front end that can redirect
> traffic, etc.) I would not trust them to act as a CA with respect to
> key security, operational security, etc.
>
The non-standard port is not something we usually see for the OCSP
responder uri. I looked through the list of included roots at
http://www.mozilla.org/projects/security/certs/included/ and none of
them specified a non-standard port for their OCSP responders.
However, I don't see how it goes against the Mozilla CA Certificate
Policy or our recommended practices. Is this something that should be
added to our recommended practices wiki page?
Is using a non-standard port any worse than the CAs that don't even
provide an OCSP service?
We do expect OCSP responders to function without error in Mozilla
products. We would not want to end up in the situation where a
significant portion of our user base is not able to make OCSP requests.
The concern that Izenpe doesn't control their infrastructure does seem
relevant. Perhaps we need to gain a better understanding of why it isn't
possible for Izenpe to set up OCSP on a standard port.
Kathleen
Kurt Seifried
> uri. I looked through the list of included roots at
> http://www.mozilla.org/projects/security/certs/included/ and none of them
> specified a non-standard port for their OCSP responders.
Is there some compelling reason to run it on a non-standard port? It's
not like this is a huge technical challenge (run it internally on port
12345, have an exterior load balancer/proxy/firewall/whatever forward
port 80 or 443 as needed to the internal port. If this can't be done I
have to say I wouldn't trust them at all.
> However, I don't see how it goes against the Mozilla CA Certificate Policy
> or our recommended practices. Is this something that should be added to our
> recommended practices wiki page?
I would say it should be added, there is a reason for using well
established "standard" ports:
1) things pass through firewalls (port 80/443 are almost always
allowed, other ports may be blocked)
2) traffic shpaing/IPS/etc. are less likely to block it
3) choosing the same sane defaults everyone else uses (there's a
reason the electrical code has you only attach white wires to other
white wires and black wires to other black wires, and not mix and
match. The same is true for services and port numbers I think).
> Is using a non-standard port any worse than the CAs that don't even provide
> an OCSP service?
I would argue it is worse. If no OCSP is offered we at least know
where we stand. If an unreliable or non-standard OCSP is offered (i.e.
strange port numbers, non-standard replies, etc.) then we have a gray
area (it may work for some and not for others) which is worse since we
think it should be or is working.
> We do expect OCSP responders to function without error in Mozilla products.
> We would not want to end up in the situation where a significant portion of
> our user base is not able to make OCSP requests.
Agreed. My main thought is: if port 80/443 are blocked than getting to
an OCSP is a moot point, if ports 80/443 are allowed but others are
blocked then we have a problem (you can be attacked since you can't
check the OCSP).
> The concern that Izenpe doesn't control their infrastructure does seem
> relevant. Perhaps we need to gain a better understanding of why it isn't
> possible for Izenpe to set up OCSP on a standard port.
Or at least port forward/etc. This is pretty easy networking stuff.
> Kathleen
--
Kurt Seifried
ku...@seifried.org
tel: 1-703-879-3176
Eddy Nigg
> I think that combined these represent a significant set of problems
> (especially #2, aka the "we can't fix it if it breaks" issue). I would
> ask that this question be re-opened and corrective action be taken
> (i.e. running the OCSP on a standard port). If the CA is
> unable/incapable of doing this due to technical/operational reasons I
> would really have to call their competency into question.
>
I would like to take this one step further. If I understood the response
from Inigo correctly, then it appears that the port 80 [1] is already
used by a different service (HTTP). This brings me to the logical
conclusion that their OCSP runs on one machine together with additional
services. It also seems, that they preferred to assign to the OCSP
responder a different port number than another IP address.
Both seems to me somewhat troublesome, because in case there will be
some increased traffic and status requests, their infrastructure
wouldn't be able to manage the load. It probably would also affect
additional services of theirs too in such a case.
Not being able to assign additional IP addresses in order to run stuff
on standard ports for critical services like OCSP suggests a lack of
understanding and competence. The bug
https://bugzilla.mozilla.org/show_bug.cgi?id=554598 which Inigo opened
isn't very favorable either.
Now, Firefox and Thunderbird are currently configured to a soft fail on
OCSP responses. The most that could happen right now would be
non-display of the green EV UI. However it would result effectively in a
non working certificate status about which the current Mozilla clients
have nothing to say. If the default would be a hard fail, we could
probably ignore this issue, because at the most the CA would get the
complaints. Because the relying parties would receive a nasty error in
their browser. So there is maybe something to consider here.
[1] I believe that port 443 should NOT be used, certainly not over
HTTPS. This might result in a loop of not being able to check the status
of the OCSP certificate, additionally it would slow down the response as
well.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Eddy Nigg
> I would like to take this one step further. If I understood the
> response from Inigo correctly, then it appears that the port 80 [1] is
> already used by a different service (HTTP). This brings me to the
> logical conclusion that their OCSP runs on one machine together with
> additional services. It also seems, that they preferred to assign to
> the OCSP responder a different port number than another IP address.
Well, I should have checked before writing, but apparently the above is
not the case. The host ocsp.izenpe.com is on IP 212.142.249.35 and
nothing runs on port 80 on that IP address. The host www.izenpe.com has
even two IP addresses configured. And now I'm scratching my head even
more about how this decision was made to run their OCSP on such an odd
port number....Inigo - HELP!?
etowers
“unusual port” 8097 is as fanciful as the choose of the “usual ports”
80/443. To argue that firewalls usually block non usual ports is a
weak and not proved argument, much more when Izenpe has affirmed they
have not found any problem during the last eight years when using non
usual ports. The idea of firewall blocking port is quite poor when
most of the problems we currently found with the firewall relies on
the “content/traffic filtering”, so we can also argue that “normal
users/entities” will block any content they will not be understand,
including protocols like OCSP which are not very used till now –once
again, this would be an issue but also quite weak-.
The establishment of “unusual ports” is quite spread in every
organization, most people does in order to protect their internal
systems, the idea behind is that you configure your system are your
own criteria and then you expose to the public network the services
you want in the way you want or need –that is in my opinion the reason
for which reverse proxies has got so much success-. The only think it
can be argued is that Izenpe should have expose a “usual port” to the
internet, whatever is the port they use internally –but once again, I
guest this is a Izenpe’s decision-. Much more, I don’t see the point
to continue arguing when the rest of browsers within the cabforum did
not.
In any case, to correct this will requires to modify the current AIA
extension to use a “usual port” –something quite simple-, Izenpe can
still use NAT or its reverse proxy to redirect previous issued
certificates to the OCSP responder. But then, the question should be
in Mozilla side, will they accept previous issued certificates? If
not, what they request to do to Izenpe? To renew the certificates,
this sound a bit –let say-, “hard”.
The Kurt’s concern 3) is out of sense, in just one sentence he has put
in doubt not only the technical skills of Izenpe but the audit
capabilities of BSI and KPMG that accredited that Izenpe is conform
to ISO 27001, WebTrust and to ETSI TS 101 456.
Kind regards
Eddy Nigg
> Since there are not specific written specifications the choose of the
> “unusual port” 8097 is as fanciful as the choose of the “usual ports”
> 80/443.
I would strongly disagree with that. Port 80 has been defined for the
HTTP service. 8097 not.
> To argue that firewalls usually block non usual ports is a
> weak and not proved argument, much more when Izenpe has affirmed they
> have not found any problem during the last eight years when using non
> usual ports.
Their OCSP responder wasn't even compliant and didn't worked for eight
years for Mozilla Firefox.
> The idea of firewall blocking port is quite poor when
> most of the problems we currently found with the firewall relies on
> the “content/traffic filtering”, so we can also argue that “normal
> users/entities” will block any content they will not be understand,
> including protocols like OCSP which are not very used till now –once
> again, this would be an issue but also quite weak-.
>
These days OCSP response is used for almost all SSL secured sites -
indeed very unusual. Corporate firewalls however regularly block
anything beyond a few allowed ports.
> In any case, to correct this will requires to modify the current AIA
> extension to use a “usual port” –something quite simple-, Izenpe can
> still use NAT or its reverse proxy to redirect previous issued
> certificates to the OCSP responder.
Correct.
> But then, the question should be
> in Mozilla side, will they accept previous issued certificates? If
> not, what they request to do to Izenpe? To renew the certificates,
> this sound a bit –let say-, “hard”.
>
I would suggest to move the OCSP responders to port 80 and leave a
shadow service for the previous ports. The previously issued
certificates will probably expire within reasonable time and the new
certificates will be directed to the regular ports. I think this should
be the correct action and solution.
Kurt Seifried
> Since there are not specific written specifications the choose of the
> “unusual port” 8097 is as fanciful as the choose of the “usual ports”
> weak and not proved argument, much more when Izenpe has affirmed they
> have not found any problem during the last eight years when using non
Ok. So will your company commit, in a signed and notarized statement
that if it is found to be a problem you will move to ports 80/443
immediately and re-issue all the existing certificates immediately?
Will you place this as an official clause in your CPS?
> The Kurt’s concern 3) is out of sense, in just one sentence he has put
> in doubt not only the technical skills of Izenpe but the audit
> capabilities of BSI and KPMG that accredited that Izenpe is conform
> to ISO 27001, WebTrust and to ETSI TS 101 456.
Just because you pass an audit doesn't make you competent. It just
means that you passed an audit.
More to the point: why are you unable to use a standard port like
everyone else? It sounds like you are either technically unable to or
operationally you don't control your infrastructure to a degree that
allows you to make decisions and must work around other people
providing your infrastructure who have final say over what is allowed.
Both are very worrying.
etowers
> HTTP service. 8097 not.
Well, you right, IANA has defined the port 80 for http, as well as few
other ones: 591, 8008, 8080. It’s also interesting to see how IANA
agree to use many other port that use http fortransport for other
protocols (the list is huge).
At this point I would like also to highlight that the OCSP protocol as
defined in the RFC2560 is transport protocol agnostic:
“The actual formatting of the message could vary depending on
the transport mechanism used (HTTP, SMTP, LDAP, etc.).”
So what it’s required to use in the AIA extensión is an URI, what if
instead of using http/s someone decide to use SMTP, LDAP, SOAP, etc,
will mozilla implement all posible transport protocols?
I’m fully agree that http/s is the best option and the one to be
followed and that well-know ports should be used to avoid future
problems but this should be write it down in a clear specification
otherwise I don’t see point to put anyone under others pesonal's
criteria.
> Their OCSP responder wasn't even compliant and didn't worked for eight
> years for Mozilla Firefox.
I’ve just test it and it works fine, the only think is that I had to
include the Izenpe hierarchy into Mozilla manually and then test it.
> These days OCSP response is used for almost all SSL secured sites -
> indeed very unusual. Corporate firewalls however regularly block
> anything beyond a few allowed ports.
Have you try it to put the AIA extension has critical? This will force
that the certificates should be checked but when I tried most of the
products reject the certificates. So, I’m afraid this is not really
true, just I would like to explain the situation we have in Spain.
Here we have a nice National ID Card -16 millions cards have been
issued, by the way 16 million of people that need to include the DNIe
root manually in Mozilla if they want to use the browser-, also there
is a couple of laws that force to the Government and the companies to
provide authenticated access with certificates to the services. Well,
most of the companies that implemented have need to create their own
mechanism to verify the status of the certificates –either using OCSP
(the least) or DSS (the most)-.
> I would suggest to move the OCSP responders to port 80 and leave a
> shadow service for the previous ports. The previously issued
> certificates will probably expire within reasonable time and the new
> certificates will be directed to the regular ports. I think this should
> be the correct action and solution.
Fully agree, I would like also to SUGGEST this change rather than to
impose. I would kindly ask to Izenpe to reconsider it’s current port
for those “general users” certificates, I assume after see the kind of
certificates they issued –most for public employees- they have not
problem in the Basque Government network to use any port.
Regards,
Emanuel
etowers
> that if it is found to be a problem you will move to ports 80/443
> immediately and re-issue all the existing certificates immediately?
I'm afraid I'm not an Izenpe's employee neither it's owner -well, just
a bit since a public company belongs to Spaniards-, but I don't see
how my company can commit with things with liabilities of third
parties.
Seriously, If a company found a problem usually it's solved for the
safe of the company, the issue here is that Izenpe afirms that they
have not found any problem and you are pushing to re-issue their
400.000 certificates because you don't like the port they are
issuing.
> > The Kurt’s concern 3) is out of sense, in just one sentence he has put
> > in doubt not only the technical skills of Izenpe but the audit
> > capabilities of BSI and KPMG that accredited that Izenpe is conform
> > to ISO 27001, WebTrust and to ETSI TS 101 456.
>
> Just because you pass an audit doesn't make you competent. It just
> means that you passed an audit.
So, if to pass an auditing process does not guarantee the compentence
why is required, how a CSP or any company can guarantee its
competence ?
If well reputed auditors are not competent -such as you suggest- who
should guarantee companies' competence.
I don't know how has been carried out the audit process you have
passed, but for me has been very hard and very helpfull -I've not pass
the ones that Izenpe, but I remember the ISO 9001 or the CC and be
sure that the auditors where quite competent-.
> More to the point: why are you unable to use a standard port like
> everyone else? It sounds like you are either technically unable to or
> operationally you don't control your infrastructure to a degree that
> allows you to make decisions and must work around other people
> providing your infrastructure who have final say over what is allowed.
> Both are very worrying.
I don't really think they are unable to do it, change a extension an
reconfiguring a reverse proxy or whatever they use is quite simple but
the change can be quite painful when you have already issue near of
400.000 certificates -not technically but in others terms-.
Particularly, I don't see the real need for the change, I've tested it
and its working and the block firewall argument is my personal opinion
very weak.