[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