Hi, Peter,
Thank you. I will reference to give credit to Erwann and reference to Erwann
and Ryan, also, there is Rich Smith's comment in
https://cabforum.org/pipermail/public/2016-July/007979.html
" My suggestion was based purely on the fact that any documented use of these
OIDs is, to the best of my knowledge, only in CA/B Forum work product, so it
seemed a good idea to me, now that we can, to transition them to actually being
CA/B Forum OIDs. I don't have strong feelings on the matter, but I do think it
makes things cleaner over the long haul, especially should we decide to add
other related OIDs into future work product, to have them managed in house.
But I do take your point as to it being a lot of technical changes, both on
browser/relying party side and CA side for what, at least at this moment in
time, has pretty much zero need or payback aside from the above mentioned
possible future 'benefits'. "
I will add to my presentation file.
As the 3 OIDs are under private enterprise OID arc and used in 2007, but
CA/Browser Forum get the approved application for CA/Browser Forum node in 2011
as
wiki:https://www.cabforum.org/wiki/Object%20Registry?action=AttachFile&do=get&target=Approved+application.pdf
, I think if browsers agree to solve Topic 1, maybe browsers change the code
when parsing Subject DN of an EV SSL certificate, they show 3 old proprietary
Microsoft OIDs and CA/Browser Forum 3 new OIDs as meaningful string.
Sincerely Yours,
Li-Chun CHEN
-----Original Message-----
From: Peter Bowen [mailto:p...@amzn.com]
Sent: Wednesday, October 05, 2016 10:10 PM
To: 陳立群
Cc: public; gerv; Dean_Coclin
Subject: Re: [cabfpub] Potential F2F Topics
Li-Chun,
Yes, please feel free to quote my proposal, but please also give credit to
Erwann, as it was based on what he wrote at
https://cabforum.org/pipermail/public/2016-June/007893.html
I would also suggest you reference
https://cabforum.org/pipermail/public/2016-July/007913.html, where Ryan Sleeve
wrote:
“[I want to] indicate that we don't feel it would be appropriate or necessary
to introduce new OID arcs for EV attributes, and would in fact be detrimental
to the ecosystem. As such, unless new information is shared to further
understand the objective, we'd vote no on any such ballot."
I’m happy to try to clarify the definitions of those three naming attributes,
but I’m still not clear on the reason to request changing their type values.
They appear to be validly assigned in the Object Identifier system, as defined
in X.660.
Thanks,
Peter
> On Oct 5, 2016, at 5:45 AM, 陳立群 <real...@cht.com.tw> wrote:
>
> Dear Peter,
>
> Yes, remove the lines with “X520” from section 9.2.5 and add the following
> is a solution. Would you mind I quote your sentences in the presentation file?
>
> Another way is using CA/Browser Forum registered OID such as
> 2.23.140.1.1.60.2.1.3, 2.23.140.1.1.60.2.1.2, 2.23.140.1.1.60.2.1.1 to
> replace 3 Microsoft registered OID and amend EVGL.
>
> Hope we have a chance to discuss in Oct. F2F meeting.
>
> Sincerely Yours,
>
> Li-Chun CHEN
>
> -----Original Message-----
> From: Peter Bowen [mailto:p...@amzn.com]
> Sent: Wednesday, October 05, 2016 1:25 AM
> To: realsky(CHT)
> Cc: public; gerv; Dean_Coclin
> Subject: Re: [cabfpub] Potential F2F Topics
>
> Li-Chun,
>
> If we removed the lines with “X520” from section 9.2.5 of the EV guidelines
> and added the following, would your concerns expressed in the Word document
> you attached be addressed?
>
> id-evat OBJECT IDENTIIER ::= {iso(1) identified-organization(3) dod(6)
> internet(1) private(4) enterprise(1) 311 60 2 1 }
>
> id-evat-jurisdictionCountryName AttributeType
> ::= { id-evat 3 }
>
> jurisdictionCountryName ATTRIBUTE ::= {
> SUBTYPE OF name
> WITH SYNTAX CountryName
> SINGLE VALUE TRUE
> LDAP-SYNTAX countryString.&id
> LDAP-NAME {"jurisdictionC"}
> ID id-evat-jurisdictionCountryName }
>
> id-evat-jurisdictionStateOrProvinceName AttributeType ::= {
> id-evat 2 }
>
> jurisdictionStateOrProvinceName ATTRIBUTE ::= {
> SUBTYPE OF name
> WITH SYNTAX DirectoryString {ub-state-name}
> SINGLE VALUE TRUE
> LDAP-SYNTAX directoryString.&id
> LDAP-NAME {"jurisdictionST"}
> ID id-evat-jurisdictionStateOrProvinceName }
>
> id-evat-jurisdictionLocalityName AttributeType ::= {
> id-evat 1 }
>
> jurisdictionLocalityName ATTRIBUTE ::= {
> SUBTYPE OF name
> WITH SYNTAX DirectoryString {ub-locality-name}
> SINGLE VALUE TRUE
> LDAP-SYNTAX directoryString.&id
> LDAP-NAME {"jurisdictionL"}
> ID id-evat-jurisdictionLocalityName }
>
> Thanks,
> Peter
>
>> On Oct 4, 2016, at 9:23 AM, 陳立群 <real...@cht.com.tw> wrote:
>>
>> I also want to hear the discussion of those 3 topics proposed by Gervase. As
>> for my proposed topic on Oct 20, please see attached powerpoint file for
>> discussion 1. Thanks for my colleague to use English windows to capture the
>> image of details in subject DN of an EV SSL certificate.
>>
>> For example, could below partial DN of detailed information of an EV
>> SSL certificate in https://github.com/
>>
>>
>> 1.3.6.1.4.1.311.60.2.1.2 = Delaware
>> 1.3.6.1.4.1.311.60.2.1.3 = US
>> 2.5.4.15 = Private Organization
>>
>> Change to
>>
>> Jurisdiction of State or Province = Delaware Jurisdiction of Country=
>> US Business Category= Private Organization
>>
>> I think it will be helpful for relying party to see the detailed information
>> of this EV SSL certificate.
>>
>> It will greatly improve user experience to browser a important site
>> installed by an EV SSL certificate
>>
>> For above topic, Could the browser vendors' representatives help to ask the
>> programming team if/when this request is met?
>>
>> If there is time on October 20, for discussion 2 I have not finished the
>> powerpoint file, but I have post the issue, please see attached word file.
>> To solve EV Guideline section 9.2.5 using the proprietary Microsoft OIDs
>> that don’t appear in X.520 and RFC 5280 as current EVGL's sentences to
>> represent the level of the Incorporating Agency or Registration Agency,
>> let's collect CAs' and Browsers' opinions.
>>
>> Sincerely Yours,
>>
>> Li-Chun CHEN
>>
>>
>> -----Original Message-----
>> From: public-boun...@cabforum.org
>> [mailto:public-boun...@cabforum.org]
>> On Behalf Of Dean Coclin
>> Sent: Tuesday, October 04, 2016 3:17 AM
>> To: Gervase Markham; CABFPub
>> Subject: Re: [cabfpub] Potential F2F Topics
>>
>> IPR is topic 13 on the agenda.
>>
>> CAA has been added. I put your name and Rick's on the list as discussion
>> leaders.
>>
>> Google CT can be discussed in their browser update.
>>
>> Regarding Li-Chun's proposed topic on browser UIs, I'd let him present what
>> he has to say before passing judgement.
>>
>> Thanks
>> Dean
>>
>> -----Original Message-----
>> From: public-boun...@cabforum.org
>> [mailto:public-boun...@cabforum.org]
>> On Behalf Of Gervase Markham
>> Sent: Monday, October 03, 2016 10:26 AM
>> To: CABFPub <public@cabforum.org>
>> Subject: Re: [cabfpub] Potential F2F Topics
>>
>> On 01/10/16 17:00, Peter Bowen wrote:
>>> I haven’t seen much recent activity on topics for the F2F. It looks
>>> like we still have most of the second day with placeholders to be
>>> filled in.
>>
>> I would like to discuss the following topics:
>>
>> 1) IPR process. Is there any appetite in the Forum for changing the IPR
>> rules to allow post-vote review (and, if the review turns up something,
>> having the ballot be put in abeyance) rather than the current pre-vote
>> review? I feel this would make the work of the Forum proceed much faster (as
>> IPR review can happen in parallel with CAs preparing to implement the
>> change), and it optimises for the common case, which is that no IPR
>> declarations are filed.
>>
>> This could be discussed in the IPR WG but perhaps it would be better
>> discussed in the whole forum to see if there was sufficient interest in
>> making this change. Perhaps members could consult their legal counsel before
>> the meeting to see what issues this might raise and how they could be solved.
>>
>> 2) CAA. Again. I think that we need to get to a place where we decide
>> to have a ballot on CAA, and it should be the ballot with the
>> greatest chance of passing. If it fails, it fails, but at the moment
>> we just keep revisiting the issue and having to have the discussion
>> again from scratch. So I'd like to have some time with the explicit
>> goal of working out what form of CAA ballot is most likely to command
>> the support of the forum. (TBH, if only 20 sites in the Alexa top 1M
>> are using it, I doubt any CA should worry that it will end up being a
>> restraint of trade!)
>>
>> 3) I'd like to hear from Google if they have any update on the timing of
>> their plans for requiring CT in other parts of the ecosystem. As they are
>> the ones running a large proportion of the servers, and whose browser has
>> the most advanced implementation, we expect them to be the first to make
>> such a requirement. I'd also, for my own interest, love to hear about their
>> and others' experiences running CT logs, how difficult it has proved to be
>> in practice to run one with 99%+ uptime, whether people are meeting various
>> performance criteria and so on.
>>
>>
>> Of course, saying I'd like these matters discussed doesn't necessarily mean
>> I'm the right person to be responsible for the discussion. I'd be happy to
>> lead 1), but 2) and 3) would be someone else.
>>
>> It's good that we now have an established practice of nominating discussion
>> leaders for each slot. It would be good if the discussion leader for each
>> slot could, _before_ we assemble, state in a couple of sentences what the
>> goal of that slot is. If the chairman could perhaps try and elicit such
>> statements from the relevant people, I feel sure that would enhance our
>> efficiency.
>>
>> I would also note that there is currently an item on the agenda "Potential
>> change to browser UI for Subject DN". It is a long-accepted truth that the
>> CAB Forum does not place requirements on browser UI. It may be worth making
>> that clear again now, so that we can use that time for other items.
>>
>> Gerv
>>
>> _______________________________________________
>> Public mailing list
>> Public@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.
>>
>>
>> <EVGLsection9.2.5_RFC5280_X.520.docx><Chunghwatelecom-cabforum2016102
>> 0 v1.pptx>_______________________________________________
>> Public mailing list
>> Public@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.
>
>
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
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.
_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
