Netlock Root Inclusion Request
Kathleen Wilson
is the next request in the queue for public discussion.
Netlock (a qualified Certificate Authority in Hungary) has applied to
add the “NetLock Arany (Class Gold) Főtanúsítvány” root certificate
and enable all three trust bits.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=480966
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#NetLock
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=380455
Noteworthy points:
* NetLock currently has four separate root certificates included in
NSS. The redesigned equivalent of these existing roots certs will be
created under this new root cert. The new root will sign 7 internally-
operated subordinate CAs. Two of those subordinate CAs will sign sub-
CAs that will be externally-operated by MKB (Hungarian Trade Bank) and
MNB (National Bank of Hungary).
** Both of the externally-operated sub-CAs only issue certificates to
their own employees.
*** They both operate a service unit for issuing non-qualified
employee signer and encryption certificates.
*** Neither of them issue SSL or code signing certificates.
*** They are not allowed to create their own sub-CAs. This is
controlled through by PATHLEN=0 and by configuration of issuing
server.
* CA Hierarchy: https://bug480966.bugzilla.mozilla.org/attachment.cgi?id=374930
** Dark Blue color = ready/usable, Light Blue = planned
* The CPS documents have been translated into English.
** Qualified certificate CPS: https://bugzilla.mozilla.org/attachment.cgi?id=364923
** Non-Qualified certificate CPS: https://bugzilla.mozilla.org/attachment.cgi?id=366607
* The request is to enable all three trust bits for this root:
Websites, Email, and Code Signing.
* Verification of Email Address Ownership/Control: In both the
Qualified and the Non-Qualified CPS documents section 4.2.2 describes
the registration procedure which includes automated confirmations and
checking of the e-mail address (if the Subject has any): NetLock
confirms the certificate application in an automated reply. The
Applicant shall send a reply to the confirmation.
* Verification of Domain Ownership/Control is specified in the
Certificate Issuance Practice Statement: https://bugzilla.mozilla.org/attachment.cgi?id=366795
** Section 3.2.7, Server identification: “With this verification the
owner of the server should be identified. ... The domain name should
be queried through public and verified name servers. The owner of that
domain who is authorized to request a certificate for that DNS name.
The verification was successful, if the owner of domain name is the
same as the requestor. If they are not same, Netlock refuses the
request.”
From Netlock: “This is a small still valid part of the 2003-02-25
dated Certificate issuance practice statement. Because the
verifications are over defined by the CPS_NQ_080206, it has only this
small block that is still valid. It’s on the server certificate
issuance domain verification.”
* Verification of Code Signing Subscriber Identity: Code Signing
certificates are handled like signer certificates and they are issued
from the qualified roots only; the profile of the code signing cert is
slightly different than the other qualified signer and has the
CodeSign EKU. The requestor of the code signing certificate is
evaluated as per the qualified CPS; its certificate is handled like a
signer certificate, exclusively given only on SSCD device.
* Test Website: https://www.schalamonek.hu/
* Both CRL and OCSP are provided under this root
** CPS section 4.10.1: Validity of the lists is at most twenty-five
(25) hours.
** CRL NextUpdate: 25 hours
** The root CA will use its OCSP responder, and subordinate CAs will
use their responder too.
*** root: http://ocsp1.netlock.hu/gold.cgi
*** Class B Legal sub-CA (signer certs): http://ocsp1.netlock.hu/cblca.cgi
*** Class B sub-CA (SSL certs): http://ocsp1.netlock.hu/cbca.cgi
* Audit: Netlock’s service for electronic signature certificates is
audited by the Hungarian National Communications Authority (NCA), and
is listed on the NCA website as a Qualified Service Provider. Netlock
is also audited by CERT Hungary, who confirmed “the new NetLock Arany
(Class Gold) Főtanúsítvány certificate authority root is operated
according to the Hungarian Act 35 of 2001 on electronic signature, the
Information and Communication Ministerial decree 3/2005 (III. 18.).
These laws orders that Hungarian CAs have to operated according to
criteria that is at least equivalent to ETSI TS 101 456 or ETSI 102
042.”
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
Netlock and provide your feedback and/or recommendation?
Thanks,
Kathleen
Eddy Nigg
> Would two people please review this root inclusion request from
> Netlock and provide your feedback and/or recommendation?
>
Kathleen, you've announced the discussion just three days ago at the
13th. I think you need to give us some more time - at least one week. I
think one week is the schedule, but if we need more time, I or anybody
else should feel free to request some more. Right now I haven't had time
to look at it, but intend to do so soonish...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Ian G
> Would two people please review this root inclusion request from
> Netlock and provide your feedback and/or recommendation?
I have no time atm, sorry.
iang
Ian G
On 12/11/2009 23:29, Kathleen Wilson wrote:
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule Netlock
> is the next request in the queue for public discussion.
>
> Netlock (a qualified Certificate Authority in Hungary) has applied to
> add the “NetLock Arany (Class Gold) Főtanúsítvány” root certificate
> and enable all three trust bits.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=480966
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#NetLock
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=380455
>
> Noteworthy points:
>
> * NetLock currently has four separate root certificates included in
> NSS. The redesigned equivalent of these existing roots certs will be
> created under this new root cert. The new root will sign 7 internally-
> operated subordinate CAs. Two of those subordinate CAs will sign sub-
> CAs that will be externally-operated by MKB (Hungarian Trade Bank) and
> MNB (National Bank of Hungary).
Are both of these agencies of the government? or are they private
organisations with interesting names?
> ** Both of the externally-operated sub-CAs only issue certificates to
> their own employees.
> *** They both operate a service unit for issuing non-qualified
> employee signer and encryption certificates.
> *** Neither of them issue SSL or code signing certificates.
> *** They are not allowed to create their own sub-CAs. This is
> controlled through by PATHLEN=0 and by configuration of issuing
> server.
> * CA Hierarchy: https://bug480966.bugzilla.mozilla.org/attachment.cgi?id=374930
> ** Dark Blue color = ready/usable, Light Blue = planned
In the limited time I had, I was not able to read that. I use a mac,
and it bungled the DOC thing. I'm sure I could, but ...
> * The CPS documents have been translated into English.
> ** Qualified certificate CPS: https://bugzilla.mozilla.org/attachment.cgi?id=364923
> ** Non-Qualified certificate CPS: https://bugzilla.mozilla.org/attachment.cgi?id=366607
>
> * The request is to enable all three trust bits for this root:
> Websites, Email, and Code Signing.
I'm uncertain what is meant by "this root". Above it says "four
separate root certificates..."
> * Verification of Email Address Ownership/Control: In both the
> Qualified and the Non-Qualified CPS documents section 4.2.2 describes
> the registration procedure which includes automated confirmations and
> checking of the e-mail address (if the Subject has any): NetLock
> confirms the certificate application in an automated reply. The
> Applicant shall send a reply to the confirmation.
>
> * Verification of Domain Ownership/Control is specified in the
> Certificate Issuance Practice Statement: https://bugzilla.mozilla.org/attachment.cgi?id=366795
> ** Section 3.2.7, Server identification: “With this verification the
> owner of the server should be identified. ... The domain name should
> be queried through public and verified name servers. The owner of that
> domain who is authorized to request a certificate for that DNS name.
> The verification was successful, if the owner of domain name is the
> same as the requestor. If they are not same, Netlock refuses the
> request.”
> From Netlock: “This is a small still valid part of the 2003-02-25
> dated Certificate issuance practice statement. Because the
> verifications are over defined by the CPS_NQ_080206, it has only this
> small block that is still valid. It’s on the server certificate
> issuance domain verification.”
I don't follow the above, but if this is an exception that is to be
cleared out some time, when is the date of expiry? If it is within the
next year, I would say "OK." (I know others will not!)
> * Verification of Code Signing Subscriber Identity: Code Signing
> certificates are handled like signer certificates and they are issued
> from the qualified roots only; the profile of the code signing cert is
> slightly different than the other qualified signer and has the
> CodeSign EKU. The requestor of the code signing certificate is
> evaluated as per the qualified CPS; its certificate is handled like a
> signer certificate, exclusively given only on SSCD device.
Under conditions where code signing === QC then this is OK.
> * Test Website: https://www.schalamonek.hu/
>
> * Both CRL and OCSP are provided under this root
> ** CPS section 4.10.1: Validity of the lists is at most twenty-five
> (25) hours.
> ** CRL NextUpdate: 25 hours
> ** The root CA will use its OCSP responder, and subordinate CAs will
> use their responder too.
> *** root: http://ocsp1.netlock.hu/gold.cgi
> *** Class B Legal sub-CA (signer certs): http://ocsp1.netlock.hu/cblca.cgi
> *** Class B sub-CA (SSL certs): http://ocsp1.netlock.hu/cbca.cgi
>
> * Audit: Netlock’s service for electronic signature certificates is
> audited by the Hungarian National Communications Authority (NCA), and
> is listed on the NCA website as a Qualified Service Provider. Netlock
> is also audited by CERT Hungary, who confirmed “the new NetLock Arany
> (Class Gold) Főtanúsítvány certificate authority root is operated
> according to the Hungarian Act 35 of 2001 on electronic signature, the
> Information and Communication Ministerial decree 3/2005 (III. 18.).
[ We should really get around to adding QC for client certs (code &
email) into the policy. ]
> These laws orders that Hungarian CAs have to operated according to
> criteria that is at least equivalent to ETSI TS 101 456 or ETSI 102
> 042.”
OK.
Is there a report from any of the above audits? If this CA is listed as
a QC provider and is registered under the QC programme of its
government, I am not formally demanding a report. But I'm interested to
read anything they've got.
> 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
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Eddy Nigg
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule Netlock
> is the next request in the queue for public discussion.
>
Thanks Kathleen!
> ** Both of the externally-operated sub-CAs only issue certificates to
> their own employees.
> *** They both operate a service unit for issuing non-qualified
> employee signer and encryption certificates.
>
Are those also used for S/MIME?
> *** Neither of them issue SSL or code signing certificates.
> *** They are not allowed to create their own sub-CAs. This is
> controlled through by PATHLEN=0 and by configuration of issuing
> server.
>
Are the external CAs audited together with the parent CA? I assume that
the server software and perhaps other services are provided by Netlock...
> * Verification of Domain Ownership/Control is specified in the
> Certificate Issuance Practice Statement: https://bugzilla.mozilla.org/attachment.cgi?id=366795
> ** Section 3.2.7, Server identification: “With this verification the
> owner of the server should be identified. ... The domain name should
> be queried through public and verified name servers. The owner of that
> domain who is authorized to request a certificate for that DNS name.
> The verification was successful, if the owner of domain name is the
> same as the requestor. If they are not same, Netlock refuses the
> request.”
>
This doesn't make much sense. Did they mean WHOIS records instead of
"name servers"?
> From Netlock: “This is a small still valid part of the 2003-02-25
> dated Certificate issuance practice statement. Because the
> verifications are over defined by the CPS_NQ_080206, it has only this
> small block that is still valid. It’s on the server certificate
> issuance domain verification.”
>
Which are those?
> * Both CRL and OCSP are provided under this root
> ** CPS section 4.10.1: Validity of the lists is at most twenty-five
> (25) hours.
> ** CRL NextUpdate: 25 hours
> ** The root CA will use its OCSP responder, and subordinate CAs will
> use their responder too.
> *** root: http://ocsp1.netlock.hu/gold.cgi
> *** Class B Legal sub-CA (signer certs): http://ocsp1.netlock.hu/cblca.cgi
> *** Class B sub-CA (SSL certs): http://ocsp1.netlock.hu/cbca.cgi
>
We obviously count on Kathleen to perform some minimal tests that this
is working correctly...
The OCSP responder on http://ocsp1.netlock.hu/gold.cgi doesn't return an
application/ocsp-response mime type. Not sure what it returns, but it
doesn't look like an OCSP response...
Eddy Nigg
>
> [ We should really get around to adding QC for client certs (code &
> email) into the policy. ]
Mozilla already accepts ETSI audits, no need to fragment certificates
levels and types further. Besides that, whatever QC means...QC
certificates don't require email validation, hence I would object for
S/MIME certs.
Ian G
> On 11/19/2009 05:39 AM, Ian G:
>>
>> [ We should really get around to adding QC for client certs (code &
>> email) into the policy. ]
>
> Mozilla already accepts ETSI audits, no need to fragment certificates
> levels and types further.
As far as I know, ETSI is not required for QC, it is only "likely." In
practice, the QC regime is controlled by the appropriate appointed
government agency, which does their own checks. Again, "likely" they
add ETSI to their regime.
My point is that QC alone is sufficient, with or without ETSI, and
should be added.
Perhaps others from European CAs can comment.
> Besides that, whatever QC means...
It means enough in law and in practice to be indisputably stronger than
anything else we deal with here.
(Whether that impresses one depends on factors outside control...)
> QC
> certificates don't require email validation, hence I would object for
> S/MIME certs.
That was just a passing remark to indicate that QCs are more
client-oriented. Server-side QCs are an anomoly.
iang
Varga Viktor
> organisations with interesting names?
They are bank companies.
The National Bank of Hungary is the Central hungarian bank.
(So maybe you can call this bank as a govermental, but there is independence between the central bank, and the government.)
> > * The request is to enable all three trust bits for this root:
> > Websites, Email, and Code Signing.
>
>
> I'm uncertain what is meant by "this root". Above it says "four
> separate root certificates..."
We are going on rollover, actualy we have 4 roots in the Firefox, and they are productive issuer certificates.
With the new root, the actual productive CA structure will be reproduced, Qualified, Non-Qualified subCA will be defined.
At now the following subCAs were produced:
-qualified (Q) - this for the qualified signer certificates
-non qualified, signer purpose (B EAT) - this for the non-qualified signer certificates
-non qualified, non signer purpose (B) - this for any other purpose than signer, for ssl, encryption, ....
> > From Netlock: “This is a small still valid part of the 2003-02-25
> > dated Certificate issuance practice statement. Because the
> > verifications are over defined by the CPS_NQ_080206, it has only this
> > small block that is still valid. It’s on the server certificate
> > issuance domain verification.”
>
>
> I don't follow the above, but if this is an exception that is to be
> cleared out some time, when is the date of expiry? If it is within the
> next year, I would say "OK." (I know others will not!)
I am working on the new CPS, and the domain validation will moved in it.
Because the new CPs is not valid yet, we can talk about the actual valid.
The strength of the validation will be the same like this.
> > * Verification of Code Signing Subscriber Identity: Code Signing
> > certificates are handled like signer certificates and they are issued
> > from the qualified roots only; the profile of the code signing cert
> is
> > slightly different than the other qualified signer and has the
> > CodeSign EKU. The requestor of the code signing certificate is
> > evaluated as per the qualified CPS; its certificate is handled like a
> > signer certificate, exclusively given only on SSCD device.
>
>
> Under conditions where code signing === QC then this is OK.
Its not realy clear for me, what is the question here.
> OK.
>
> Is there a report from any of the above audits? If this CA is listed
> as
> a QC provider and is registered under the QC programme of its
> government, I am not formally demanding a report. But I'm interested
> to
> read anything they've got.
Yes, you can check the official list on this page:
This is for qualified:
http://webold.nhh.hu/esign/szolgParams/init.do?tipus=mi
And this for the non qualified:
http://webold.nhh.hu/esign/szolgParams/init.do?tipus=fb
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
_______________________________________________________________________
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 ________________________________________________________________________________________
Ian G
>> Are both of these agencies of the government? or are they private
>> organisations with interesting names?
>
> They are bank companies.
>
> The National Bank of Hungary is the Central hungarian bank.
> (So maybe you can call this bank as a govermental, but there is independence between the central bank, and the government.)
Right, the central bank are above the government or at least they act
that way :)
The fundamental assumption of risk is this: any larger government
department or quasi-government or agency are generally low risk to
Mozilla / end-users. I think the term of art is "big enough and ugly
enough to look after themselves." And their people, who suffer mightily
at the hands of their government, so a little more won't hurt them.
The Hungarian Trade Bank -- is that a private bank? Is it a
quasi-governmental organisation or a fully commercial operator? This
makes a bit of a difference.
If it was a fully commercial operator, *and* the contract between the
operator and the CA is for internal use only, then this is nicely
firewalled. If however, the subCA is used to issue certs externally,
this becomes an issue.
>>> * The request is to enable all three trust bits for this root:
>>> Websites, Email, and Code Signing.
>>
>>
>> I'm uncertain what is meant by "this root". Above it says "four
>> separate root certificates..."
>
> We are going on rollover, actualy we have 4 roots in the Firefox, and they are productive issuer certificates.
>
> With the new root, the actual productive CA structure will be reproduced, Qualified, Non-Qualified subCA will be defined.
>
> At now the following subCAs were produced:
> -qualified (Q) - this for the qualified signer certificates
> -non qualified, signer purpose (B EAT) - this for the non-qualified signer certificates
> -non qualified, non signer purpose (B) - this for any other purpose than signer, for ssl, encryption, ....
OK, got it.
>>> From Netlock: “This is a small still valid part of the 2003-02-25
>>> dated Certificate issuance practice statement. Because the
>>> verifications are over defined by the CPS_NQ_080206, it has only this
>>> small block that is still valid. It’s on the server certificate
>>> issuance domain verification.”
>>
>>
>> I don't follow the above, but if this is an exception that is to be
>> cleared out some time, when is the date of expiry? If it is within the
>> next year, I would say "OK." (I know others will not!)
>
> I am working on the new CPS, and the domain validation will moved in it.
>
> Because the new CPs is not valid yet, we can talk about the actual valid.
> The strength of the validation will be the same like this.
>
>>> * Verification of Code Signing Subscriber Identity: Code Signing
>>> certificates are handled like signer certificates and they are issued
>>> from the qualified roots only; the profile of the code signing cert
>> is
>>> slightly different than the other qualified signer and has the
>>> CodeSign EKU. The requestor of the code signing certificate is
>>> evaluated as per the qualified CPS; its certificate is handled like a
>>> signer certificate, exclusively given only on SSCD device.
>>
>>
>> Under conditions where code signing === QC then this is OK.
>
> Its not realy clear for me, what is the question here.
No question for me. Above, it is implied that code signing is only
issued under the QC subRoot. This is fine.
>> Is there a report from any of the above audits? If this CA is listed
>> as
>> a QC provider and is registered under the QC programme of its
>> government, I am not formally demanding a report. But I'm interested
>> to
>> read anything they've got.
>
> Yes, you can check the official list on this page:
>
> This is for qualified:
> http://webold.nhh.hu/esign/szolgParams/init.do?tipus=mi
>
> And this for the non qualified:
> http://webold.nhh.hu/esign/szolgParams/init.do?tipus=fb
OK, I see that the NetLock is listed. I was more after any audit
reports. But optional.
iang
Varga Viktor
> that way :)
>
> The fundamental assumption of risk is this: any larger government
> department or quasi-government or agency are generally low risk to
> Mozilla / end-users. I think the term of art is "big enough and ugly
> enough to look after themselves." And their people, who suffer
> mightily
> at the hands of their government, so a little more won't hurt them.
>
> The Hungarian Trade Bank -- is that a private bank? Is it a
> quasi-governmental organisation or a fully commercial operator? This
> makes a bit of a difference.
>
> If it was a fully commercial operator, *and* the contract between the
> operator and the CA is for internal use only, then this is nicely
> firewalled. If however, the subCA is used to issue certs externally,
> this becomes an issue.
The Trade bank is a fully commercial operator.
> No question for me. Above, it is implied that code signing is only
> issued under the QC subRoot. This is fine.
This is the present. In the future, we will separate more accurately, and the code signing will be issued from one of the new roots, to separate the functions.
Wth the new root, it is possible, because the new root will issue productive CAs and will not issue end user certificates.
Varga Viktor
> > certificates don't require email validation, hence I would object for
> > S/MIME certs.
I cant agree.
In the QC there is email, so we check that.
With QC you can sign everything, the signature has the power by the law.
You should not use it to authentication, so for a QC a client auth is not allowed on server side.
> That was just a passing remark to indicate that QCs are more
> client-oriented. Server-side QCs are an anomoly.
Server side QC is possible, but to include other than a natural person personal data into a certificate is not allowed int he RFC, ETSI, ETC :D (i dont count the O, OU, it is possible ofcours, but the subject should be a natural person)
Moudrick M. Dadashov
Ian G wrote:
> On 19/11/2009 05:27, Eddy Nigg wrote:
>> On 11/19/2009 05:39 AM, Ian G:
>>>
>>> [ We should really get around to adding QC for client certs (code &
>>> email) into the policy. ]
>>
>> Mozilla already accepts ETSI audits, no need to fragment certificates
>> levels and types further.
>
>
> As far as I know, ETSI is not required for QC, it is only "likely."
> In practice, the QC regime is controlled by the appropriate appointed
> government agency, which does their own checks. Again, "likely" they
> add ETSI to their regime.
>
> My point is that QC alone is sufficient, with or without ETSI, and
> should be added.
>
> Perhaps others from European CAs can comment.
>
>
>> Besides that, whatever QC means...
>
>
> It means enough in law and in practice to be indisputably stronger
> than anything else we deal with here.
>
> (Whether that impresses one depends on factors outside control...)
>
>
>> QC
>> certificates don't require email validation, hence I would object for
>> S/MIME certs.
>
however a CA must carefully verify everything included in the
certificate it issues. I'm not sure if "unverified" email falls passes
this filter requirement.
>
> That was just a passing remark to indicate that QCs are more
> client-oriented. Server-side QCs are an anomoly.
>
>
Very much so.
M.D.
cell: +370-699-26662
> iang
Eddy Nigg
> however a CA must carefully verify everything included in the
> certificate it issues. I'm not sure if "unverified" email falls passes
> this filter requirement.
>
>
I fail to see where the problem in this respect. The so-called QC certs
have a specific purpose, primarily to sign documents and other
commitments, they usually are accepted by law equal to hand-signed
signatures of the respective country (but in no other countries, hence
there are clear limits).
In the context of software like email clients (in particular
Thunderbird, but also most others) the important parameter is the email
address, not the common name. It's not that hard to get...
Moudrick M. Dadashov
If I understood correctly, the message I commented was saying that an
unverified email in the QC was ok. I don;t think so. :)
M.D.
cell: +370-699-26662
Eddy Nigg
> Hi Eddy,
>
> If I understood correctly, the message I commented was saying that an
> unverified email in the QC was ok. I don;t think so. :)
>
Ah great! We meant the same thing...
Ian G
>>> QC
>>> certificates don't require email validation, hence I would object for
>>> S/MIME certs.
I don't think I wrote those words above, but I'll collect the bullet and
add it to my collection :)
> I cant agree.
> In the QC there is email, so we check that.
>
> With QC you can sign everything, the signature has the power by the law.
> You should not use it to authentication, so for a QC a client auth is not allowed on server side.
OK, that's a point, isn't it! So, what do you recommend is done with
S/MIME email, and QC certs? Just curious. At CAcert it is recommended
that all S/MIME messages should be signed always and the digsig is never
a person's signature, alone).
(This is off the core topic of the evaluation.)
>> That was just a passing remark to indicate that QCs are more
>> client-oriented. Server-side QCs are an anomoly.
>
> Server side QC is possible, but to include other than a natural person personal data into a certificate is not allowed int he RFC, ETSI, ETC :D (i dont count the O, OU, it is possible ofcours, but the subject should be a natural person)
Right. A topic that'll cost some beers.
iang
Varga Viktor
> have a specific purpose, primarily to sign documents and other
> commitments, they usually are accepted by law equal to hand-signed
> signatures of the respective country (but in no other countries, hence
> there are clear limits).
>
> In the context of software like email clients (in particular
> Thunderbird, but also most others) the important parameter is the email
> address, not the common name. It's not that hard to get...
Yes, you have right. A QC has more strength than a non-QC, by the law.
Generaly you can sign a mail with QC to give the strength I talked above.
So this is why the email address in the certificate, and the mail address is always verified.
Varga Viktor
> certificate it issues. I'm not sure if "unverified" email falls passes
> this filter requirement.
>
The email adresses are always verified.
Varga Viktor
> > Server side QC is possible, but to include other than a natural
> person personal data into a certificate is not allowed int he RFC,
> ETSI, ETC :D (i dont count the O, OU, it is possible ofcours, but the
> subject should be a natural person)
>
>
> Right. A topic that'll cost some beers.
It's not problem for me to get some beer. Maybe a CA conference with a lot is a good options somewhere. :D
Regards, Viktor
Kathleen Wilson
participating in this discussion.
Here is a summary of the discussion:
1) I am not sure if all of Iang’s questions about the external CAs
(banks/governmental) were covered. Iang?
2) Netlock has the action item to consolidate their procedures for
validating the ownership/control of the domain for SSL certs into
their new CPS. This may be tracked separately from inclusion, because
their procedures are currently documented and in practice.
3) OCSP testing
The test website, https://www.schalamonek.hu/, loads into Firefox
without error when OCSP is enforced. It’s SSL cert has AIA extension
OCSP: URI: http://ocsp1.netlock.hu/cbca.cgi
OCSP: URI: http://ocsp2.netlock.hu/cbca.cgi
OCSP: URI: http://ocsp3.netlock.hu/cbca.cgi
That’s the extent of my OCSP testing.
Eddy did his own testing and found:
The OCSP responder on http://ocsp1.netlock.hu/gold.cgi doesn't return
an
application/ocsp-response mime type. Not sure what it returns, but it
doesn't look like an OCSP response...
This needs to be resolved and it needs to be shown that all of these
OCSP responders are working correctly. Action is on Netlock to do this
asap.
Thanks,
Kathleen
Ian G
> All, Thank you for reviewing this root inclusion request and
> participating in this discussion.
>
> Here is a summary of the discussion:
>
> (banks/governmental) were covered. Iang?
No. For the central bank - no more questions.
The Hungarian Trade Bank has been described by Viktor as a fully
commercial operator. So basically this is "a bank" like any other.
> Two of those subordinate CAs will sign sub-
> CAs that will be externally-operated by MKB
> (Hungarian Trade Bank) and MNB (National Bank of Hungary).
So basically this is a subCA that will be externally operated. The
question then arises what is the audit regime.
If a subCA were in a government operation, I am inclined to give it a
pass on this question.
If this is a private but extremely reputable operation (so we rely on
them to do the right thing, and an audit will not tell us more) *and*
they do not issue their certificates outside their own operation, then
I'm inclined to give them a pass.
This would include a bank that was nationally regulated.
However if the certs are issued outside, e.g., to retail purchasers
coming off the street, then this is more like *another commercial CA*.
So either the audit covers this other commercial CA, or the CA has an
independent audit. Or something.
I'm not following the line that everything has to be audited here. It
is the auditor's responsibility to cover most everything and to make a
statement of what has been covered. However, there are some areas where
things have been done completely outside, so we need to establish some
sort of line here. Without throwing in costs just because we can spell
the word audit.
iang
Varga Viktor
> On 23/11/2009 23:39, Kathleen Wilson wrote:
> > All, Thank you for reviewing this root inclusion request and
> > participating in this discussion.
> >
> > Here is a summary of the discussion:
> >
> > 1) I am not sure if all of Iang's questions about the external CAs
> > (banks/governmental) were covered. Iang?
>
> No. For the central bank - no more questions.
This is then OK.
> The Hungarian Trade Bank has been described by Viktor as a fully
> commercial operator. So basically this is "a bank" like any other.
>
> > Two of those subordinate CAs will sign sub-
> > CAs that will be externally-operated by MKB
> > (Hungarian Trade Bank) and MNB (National Bank of Hungary).
>
> So basically this is a subCA that will be externally operated. The
> question then arises what is the audit regime.
>
> If a subCA were in a government operation, I am inclined to give it a
> pass on this question.
>
> If this is a private but extremely reputable operation (so we rely on
> them to do the right thing, and an audit will not tell us more) *and*
> they do not issue their certificates outside their own operation, then
> I'm inclined to give them a pass.
>
> This would include a bank that was nationally regulated.
>
> However if the certs are issued outside, e.g., to retail purchasers
> coming off the street, then this is more like *another commercial CA*.
> So either the audit covers this other commercial CA, or the CA has an
> independent audit. Or something.
This subCA for the commercial bank operates like a part of the Netlock, you can see in its certificate, that it has in the organization field the Netlock as organization. The audit implies the subCAs too, because, this is a Netlock subCA.
These organizations are not a resellers in both case.
The MKBs CA certificate subject field:
Subject:
countryName = HU
localityName = Budapest
organizationName = NetLock Kft.
organizationalUnitName = Tanúsítványkiadók
commonName = MKB Hitelesítő Alegység
Do you need some more info?
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
_______________________________________________________________________
Ian G
> This subCA for the commercial bank operates like a part of the Netlock, you can see in its certificate, that it has in the organization field the Netlock as organization. The audit implies the subCAs too, because, this is a Netlock subCA.
>
> These organizations are not a resellers in both case.
>
>
> The MKBs CA certificate subject field:
> Subject:
> countryName = HU
> localityName = Budapest
> organizationName = NetLock Kft.
> organizationalUnitName = Tan�s�tv�nykiad�k
> commonName = MKB Hiteles�t� Alegys�g
>
> Do you need some more info?
Ah, then I misunderstood. For some reason I thought that the subCAs
were operated independently in the banks concerned. But if they are
part of NetLock and operated on behalf of the banks, and as you say part
of audit, there is no difference.
iang
Varga Viktor
Because the local authority needs to be audited on all of your sites.
Ü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 Ian G
> Sent: Tuesday, November 24, 2009 6:09 PM
> Cc: dev-secur...@lists.mozilla.org
> Subject: Re: Netlock Root Inclusion Request
>
> On 24/11/2009 17:26, Varga Viktor wrote:
>
> > This subCA for the commercial bank operates like a part of the
> Netlock, you can see in its certificate, that it has in the
> organization field the Netlock as organization. The audit implies the
> subCAs too, because, this is a Netlock subCA.
> >
> > These organizations are not a resellers in both case.
> >
> >
> > The MKBs CA certificate subject field:
> > Subject:
> > countryName = HU
> > localityName = Budapest
> > organizationName = NetLock Kft.
> > organizationalUnitName = Tanúsítványkiadók
> > commonName = MKB Hitelesítő Alegység
> >
> > Do you need some more info?
>
>
> Ah, then I misunderstood. For some reason I thought that the subCAs
> were operated independently in the banks concerned. But if they are
> part of NetLock and operated on behalf of the banks, and as you say
> part
> of audit, there is no difference.
>
>
>
> iang
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Kathleen Wilson
comments and feedback to this discussion. Your contributions are
greatly appreciated.
This discussion was in regards to the request from Netlock to add the
"NetLock Arany (Class Gold) Főtanúsítvány" root certificate and enable
all three trust bits.
The discussion about Netlock's OCSP only supporting POST and not GET
has been moved into a different thread. Netlock has stated: "I will
start the process to have available OCSP with GET method, if we
resolve the previous mentioned RFC problem." I do not plan to track
this action item. I have already verified that the OCSP responder for
SSL certs works within the Firefox browser.
Therefore, there is only one action item resulting from this
discussion that I plan to track:
ACTION Netlock: Consolidate the documentation of Netlock's procedures
for validating the ownership/control of the domain for SSL certs into
the new CPS.
This may be tracked separately from inclusion, because their
procedures are currently documented and in practice. I will track this
action item in the bug.
I will post a summary of the request and my recommendation for
approval in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=480966
I am now closing this discussion. Any further follow-up on this
request should be added directly to the bug.
Thanks,
Kathleen