[cabfcert_policy] [cabfpub] "Rob's tool" (was Re: Ballot 161 - Notification of incorrect issuance)
王文正
wcwang at cht.com.tw
Wed Feb 17 07:34:37 MST 2016
We know that the current BR tends to interpret the localityName and stateOrProvinceName attributes as identifying the subject’s address of existence or operation. However, to enforce this kind of interpretation and require the Subject DN must at least contain either the localityName and stateOrProvinceName attributes may cause problem in some situations, especially in some small country where organizations are allowed to be registered at country-level. For example, in Taiwan, a corporation can be registered at country-level but can also be register at city/county-level. If there is a country-level corporation named “Farmer’s Association” of which physical address is located in Taipei City, with current Subject DN rule of BR, its Subject DN will be “C=TW, L=Taipei City, O=Farmer’s Association”. However, if there is also a city/county-level “Farmer’s Association” in Taipei City, its Subject DN will also be “C=TW, L=Taipei City, O=Farmer’s Association”. How do you distinguish them by DN?
I do not understand why we need to enforce require the Subject DN must at least contain either the localityName and stateOrProvinceName attributes if the registered organizational name of a country-level corporation/organization is already guaranteed to be unique under the country name?
The following diagram is taken from Annex B of ITU-T X.521 (Suggested name form and Directory information tree structures). Please note path 1 -> 3, it suggests that there is no need to include a Locality attribute in the directory name of a country-level organization.
[cid:image001.png at 01D169D3.5ED33150]
Wen-Cheng Wang
From: Peter Bowen [mailto:pzb at amzn.com]
Sent: Wednesday, February 17, 2016 9:13 PM
To: 陳立群
Cc: Rob Stradling; kirk_hall at trendmicro.com; policyreview at cabforum.org; 王文正; Dean Coclin
Subject: Re: [cabfcert_policy] [cabfpub] "Rob's tool" (was Re: Ballot 161 - Notification of incorrect issuance)
I think there is a misunderstanding. The address represented in the certificate by the plain localityName and stateOrProvinceName attributes is the Applicant’s address of existence or operation, not their jurisdiction of incorporation. The BRs note that a utility bill or bank statement can be used to verify the address.
For example, https://crt.sh/?id=11206357&opt=cablint shows that the FQDN is www.fenton.com.tw<http://www.fenton.com.tw>. The contact information provided on the website (http://www.fenton.com.tw/index.php?route=information/contact) is 高雄市新興區民權一路251號24樓之2. Assuming you verify that this is the address of the applicant, then you could include 高雄市 (or Kaohsiung) in the localityName or stateOrProvinceName field.
I don’t think there is any need to update the BRs for this case.
There is a need to update the BRs to cover the very limited case where a country-level jurisdiction has no reported subdivisions in ISO-3166 and the CA is unable to identify a suitable locality name. I’m having a very hard time finding such a case, but it is reported to exist.
Thanks,
Peter
On Feb 17, 2016, at 2:43 AM, 陳立群 <realsky at cht.com.tw<mailto:realsky at cht.com.tw>> wrote:
Dear Rob,
Thank you very much for your tool.
For below “error” in certificate, we have discuss it in 33th F2F meeting as https://www.cabforum.org/wiki/Meeting%2033%20Minutes?action=AttachFile&do=view&target=Suggestions-to-Correct-Documents.pdf
and put it in bug 2<https://bugzilla.cabforum.org/show_bug.cgi?id=2> . I think Ben will lead to discuss the modification of BR in this F2F meeting.
crt.sh<https://crt.sh/?> CA Search
Criteria
CA ID = '1770'
crt.sh CA ID
1770
CA Name/Key
Subject:
organizationalUnitName = Public Certification Authority - G2
organizationName = "Chunghwa Telecom Co., Ltd."
countryName = TW
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:e8:65:bf:51:6a:3b:5f:cb:2e:60:83:07:a8:7a:
33:04:69:32:8a:00:b5:da:f2:cf:d2:3b:f9:3a:35:
a1:f6:6f:9e:60:cf:74:81:31:ac:f2:59:69:fc:ad:
75:27:76:6f:ff:b7:41:c9:89:b1:3f:99:62:73:6d:
42:a1:98:cc:6d:a0:e3:c2:2f:9a:06:4d:d9:31:2a:
c3:44:70:8a:a0:4a:75:10:22:17:38:1d:1b:93:7d:
57:0b:35:2e:fa:31:81:3a:1e:92:e5:0f:31:97:e4:
17:d5:a8:87:5f:cd:ef:98:fd:3d:8c:9b:bc:41:be:
dc:6e:e3:c4:92:f6:9a:15:ef:d0:6c:3f:bc:3b:84:
85:00:a3:b8:0b:06:19:e8:bc:d2:ca:68:a1:5c:8b:
f6:e7:a2:4d:b8:47:fb:a7:ec:f2:87:e4:7d:54:96:
10:af:86:c4:b2:b8:cb:cc:08:be:e9:91:e6:a7:d0:
26:0e:fa:e7:13:21:9e:c2:a1:bc:ee:ce:91:ad:86:
dc:65:b7:da:d2:47:d5:e9:cc:72:99:ec:74:ab:fb:
f0:f3:fe:2f:94:1b:a7:90:e6:9a:45:b3:e8:0f:21:
04:19:00:a0:6e:5a:d0:8d:c0:a5:be:e8:a1:1f:27:
e9:08:cf:86:2a:24:ff:d8:56:92:de:1b:44:55:e7:
b8:39
Exponent: 65537 (0x10001)
Certificates
Not Before
Not After
Issuer Name
2014-12-11
2034-12-11
C=TW, O="Chunghwa Telecom Co., Ltd.", OU=ePKI Root Certification Authority<https://crt.sh/?id=6503676>
2014-12-11
2034-12-11
C=TW, O="Chunghwa Telecom Co., Ltd.", OU=ePKI Root Certification Authority<https://crt.sh/?id=11903324>
CA/B Forum lint
For Issued Certificates with notBefore >= 2016-02-10:
Issue
# Affected Certs
ERROR: BR certificates with organizationName must include either localityName or stateOrProvinceName
1<https://crt.sh/?cablint=10&iCAID=1770>
INFO: TLS Server certificate identified
1<https://crt.sh/?cablint=7&iCAID=1770>
Issued Certificates
Select search type:
Enter search term:
(% = wildcard)
Search options:
Exclude expired certificates?
Parent CAs
C=TW, O="Chunghwa Telecom Co., Ltd.", OU=ePKI Root Certification Authority<https://crt.sh/?caid=370>
Child CAs
None found
Li-Chun CHEN<mailto:lcchen.cissp at gmail.com> 2016-02-05 01:29:17 MST
After discussion in Chunghwa Telecom, Dr. Wen-Cheng Wang suggests to amend subsections 7.1.4.2.2 d/e as below:
d. Certificate Field: subject:localityName (OID: 2.5.4.7)
Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.
Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the
subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the
subject:countryName field has a centralized registry for that kind of organizations so that the
organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.
Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.
e. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)
Required if the subject:organizationName field is present and subject:localityName field is absent.
Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the
subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the
subject:countryName field has a centralized registry for that kind of organizations so that the
organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.
Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.
Sincerely Yours,
Li-Chun CHEN
Senior Engineer
CISSP, CISA, CISM, PMP,
Information & Communication Security Dept.
Data Communication Business Group
Chunghwa Telecom Co. Ltd.
realsky at cht.com.tw<mailto:realsky at cht.com.tw>
+886-2-2344-4820#4025
Taiwan
-----Original Message-----
From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Rob Stradling
Sent: Friday, February 05, 2016 8:18 PM
To: Doug Beattie; Barreira Iglesias, Iñigo; Ryan Sleevi; Rick Andrews; Peter Bowen
Cc: public at cabforum.org<mailto:public at cabforum.org>
Subject: [cabfpub] "Rob's tool" (was Re: Ballot 161 - Notification of incorrect issuance)
I don't think anyone's actually posted the links to this list yet, so here they are...
https://crt.sh/?cablint=1+week
is a regularly auto-updated per-CA summary of "issues" found in certs that have notBefore dates within the past 1 week. From this page you can drill down to find the affected certs.
https://crt.sh/?cablint=issues
shows the number of certs affected by each "issue". From this page you can drill down to see which CAs are responsible for each "issue", and then drill down further to find the affected certs.
The clever stuff (i.e. diagnosing the "issues") is done by Peter Bowen's excellent "cablint" tool (https://github.com/awslabs/certlint). :-)
On 05/02/16 11:50, Doug Beattie wrote:
> Inigo,
>
> The security of the ecosystem can only be improved if all CAs are doing the same thing, otherwise the attacker will go to the one which is not implementing the feature, CT in this case. The same is true for CAA where there is not much benefit until everyone is doing it.
>
> I also oppose this ballot because of the level at which "incorrect issuance" is being requested. For real misissuance when a certificate was falsely approved or a bug exploited to receive a certificate, sure, I have no issue with that. But if the reporting needs to include typos, the improper encoding of a field, minor non-compliance with referenced specs like RFC5280 then no, this is not something I can support. It's both vague, and in my view, unnecessary at that level. All you need to do is use Rob's tool and you'll fine errors in certificates from virtually every CA. The CABF would be flooded with irrelevant notices of misissuance which would make it harder to understand the real ones. The bar for reporting needs to be higher that proposed in the current ballot.
>
> CAs need to think hard about voting for this ballot because the increased scope of misissuance will lead to increased WT audit findings as well as add workload to report problems via 2 different methods, as Inigo points out.
>
> Let's see if we can work something out at the F2F that works for everyone.
>
> Doug
>
>
>
>
>> -----Original Message-----
>> From: "Barreira Iglesias, Iñigo" [mailto:i-barreira at izenpe.eus]
>> Sent: Friday, February 5, 2016 3:02 AM
>> To: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Ryan Sleevi
>> <sleevi at google.com<mailto:sleevi at google.com>>; Rick Andrews <Rick_Andrews at symantec.com<mailto:Rick_Andrews at symantec.com>>
>> Cc: public at cabforum.org<mailto:public at cabforum.org>
>> Subject: RE: [cabfpub] Ballot 161 - Notification of incorrect
>> issuance
>>
>> Doug,
>>
>> You can log all your SSL certs in the CT logs now, there´s no
>> "technical" or "legal" restrictions to do so. If you consider that
>> logging all SSL certs issued will improve the transparency, then do
>> it. We are doing it for the same reasoning but also consider that
>> this is not the "unique" solution and there are other options to
>> improve the whole ecosystem, and this ballot could be one for sure.
>> But, what I indicated is to work together and not having 2 similar
>> procedures/processes for the same goal, which is what is stated in
>> eIDAS regulation article 19 and that affects to lots of CAs. So, what
>> I´m against is to have a procedure for the CABF and another one
>> (quite similar or
>> not) according to eIDAS when the goal is the same.
>>
>> Regards
>>
>>
>> Iñigo Barreira
>> Responsable del Área técnica
>> i-barreira at izenpe.eus<mailto:i-barreira at izenpe.eus>
>> 945067705
>>
>>
>>
>> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
>> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada
>> (helbidea gaizki idatzi, transmisioak huts egin) eman abisu
>> igorleari, korreo honi erantzuna. KONTUZ!
>> ATENCION! Este mensaje contiene informacion privilegiada o
>> confidencial a la que solo tiene derecho a acceder el destinatario.
>> Si usted lo recibe por error le agradeceriamos que no hiciera uso de
>> la informacion y que se pusiese en contacto con el remitente.
>>
>> -----Mensaje original-----
>> De: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org]
>> En nombre de Doug Beattie
>> Enviado el: jueves, 04 de febrero de 2016 18:34
>> Para: Ryan Sleevi; Rick Andrews
>> CC: public at cabforum.org<mailto:public at cabforum.org>
>> Asunto: Re: [cabfpub] Ballot 161 - Notification of incorrect issuance
>>
>>
>>>> On Wed, Feb 3, 2016 at 5:07 PM, Rick Andrews
>> <Rick_Andrews at symantec.com<mailto:Rick_Andrews at symantec.com>> wrote:
>>>> In summary, Symantec can’t support this ballot. Symantec instead
>>>> recommends adoption of a new ballot that would require all publicly
>>>> trusted CAs to log all their issued certificates in accordance with
>>>> the Google EV/CT Plan. This requirement should provide CAs a
>>>> reasonable amount of time to complete implementation, and to
>>>> address
>> privacy concerns, Symantec further recommends that all certificates
>> be logged in 6962-bis-compliant CT log servers.
>>
>>> Given that no 6962-bis-compliant CT log servers exist, and 6962-bis
>>> continues to be worked on as the lessons learned from CT are
>>> applied, what timeframe do you see as reasonable? While it's
>>> understandable that Symantec is expected to comply with this policy
>>> in four months, regardless of the status of 6962-bis, it would be
>>> helpful to know what you
>> believe is reasonable.
>>
>> GlobalSign endorses the plan presented by Rick and we would be ready
>> to support a mandatory CT effective date of December 1, 2016 for
>> compliance with the Google EV/CT Plan for all SSL certificates,
>> provided 6962-bis is approved at least 4 months prior to this date
>> and there are a sufficient number of CT logs to use with this updated
>> RFC. We would support earlier, interim dates for mandatory posting
>> all DV certificates to CT logs post issuance (without included SCTs).
>> While this isn’t necessarily compliant with the Google EV/CT plan, it
>> would improve transparency sooner and define a phased plan.
>>
>> We would also support the use of CAA to flag orders for manual review
>> to further strengthen issuance processes with pre-issuance checks to
>> supplement CT logging by December 1, 2016.
>>
>> Doug
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org<mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com<http://www.comodo.com/>
COMODO CA Limited, Registered in England No. 04058690 Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
_______________________________________________
Policyreview mailing list
Policyreview at cabforum.org<mailto:Policyreview at cabforum.org>
https://cabforum.org/mailman/listinfo/policyreview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160217/98e1afbc/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 30620 bytes
Desc: image001.png
Url : https://cabforum.org/pipermail/policyreview/attachments/20160217/98e1afbc/attachment-0001.png
More information about the Policyreview
mailing list