[cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.

Ryan Hurst ryan.hurst at globalsign.com
Fri Jul 19 19:01:05 UTC 2013


FYI The ballot that caused this problem was 80:

Yes: Buypass, DigiCert, GoDaddy, Logius PKIoverheid, StartCom, Symantec, T-Systems, Trend Micro, Trustis, Opera, and Mozilla. 
No: KEYNECTIS 
Abstain: GlobalSign

I had no hand in writing the proposed ballot but think its sane and in the best interest of the Internet. 

I don't see why ballot 80 which was already accepted by this group should stop 105 clarifying the existing allowance for name constraints usage.

 

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: ryan.hurst at globalsign.com
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Jul 19, 2013, at 10:42 PM, Ryan Hurst <ryan.hurst at globalsign.com> wrote:

> I agree, the problem Microsoft is concerned with here is the decision to require the new OCSP behavior (which I believe they voted for) all this one clause does is lessen the impact of that prior decision in a sane way and does not preclude lessening the impact further via another ballot.
> 
> If folks want to revisit he date for the OCSP behavior change I would understand why and depending on the nature of the proposal I would likely be in support but that seems orthogonal to this ballot.
> 
> Ryan Hurst
> Chief Technology Officer
> GMO Globalsign
> 
> twitter: @rmhrisk
> email: ryan.hurst at globalsign.com
> phone: 206-650-7926
> 
> Sent from my phone, please forgive the brevity.
> 
> On Jul 19, 2013, at 8:42 PM, Gervase Markham <gerv at mozilla.org> wrote:
> 
>> On 18/07/13 19:23, Tom Albertson wrote:
>>> I wanted to comment on the question of industry support for Section
>>> 13.2.6, which this ballot builds upon. We may want to consider amending
>>> it now instead of proceeding further with the language in 13.2.6, as
>>> this ballot does.  In fact ballot 105 compounds our earlier error in
>>> dictating product design details to OCSP responder vendors without
>>> thinking very heavilyabout the impact.
>> 
>> I would say it does the opposite; it reduces the impact of the earlier
>> change by making fewer OCSP responder operators need to care about the
>> need to hook up to a cert DB.
>> 
>> Of course, one person's "product design details" is another person's
>> "accurate security information" :-)
>> 
>>> It’s our collective mistake –
>>> let’s not make it worse.
>> 
>> I disagree it was a mistake, but if it was, this change makes it better,
>> not worse :-)
>> 
>> Gerv
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2098 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130719/3ea7485c/attachment-0001.p7s>


More information about the Public mailing list