[cabfpub] Ballot 167 - Baseline Requirements Corrections
jeremy.rowley at digicert.com
Fri Apr 15 19:22:06 UTC 2016
There was a discussion back when the CAB Forum moved away from Good on pkix. Let me find the email thread.
From: Peter Bowen [mailto:pzb at amzn.com]
Sent: Friday, April 15, 2016 1:16 PM
To: Jeremy Rowley
Subject: Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections
I cannot find any RFC in the list that says CAs should respond “good”. In fact the word “good” only appears twice in the RFCs listed, both in contexts unrelated to revocation:
RFC 5280, section 22.214.171.124: "In some situations, devices are given certificates for which no good expiration date can be assigned. For example, a device could be issued a certificate that binds its model and serial number to its public key; such a certificate is intended to be used for the entire lifetime of the device."
RFC 4055, section 8: "Generally, good cryptographic practice employs a given RSA key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security.”
So I’m rather confused on where you see the conflict.
> On Apr 15, 2016, at 12:03 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> The BRs require responding "revoked" if the certificate has not been issued while the RFCs specified that the CA should respond "Good".
> There is one issue I'm looking at that I plan to ballot soon (although I'm still doing research on the number of instances impacted). Microsoft crypto pre-Windows 10 does not support IP Address in the SAN:iPAddress. It must be in SAN:DNS. Considering that Windows 8 has not been deprecated, I'm planning on a ballot that would permit SAN:DNS to have IP Addresses until Windows 8 is no longer a factor. Any support for this?
> -----Original Message-----
> From: Peter Bowen [mailto:pzb at amzn.com]
> Sent: Friday, April 15, 2016 1:02 PM
> To: Jeremy Rowley
> Cc: CABFPub
> Subject: Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections
> Thank you for raising this up — I was unaware there was a conflict. Can you be a little more specific on the lack of alignment? I didn’t think this was changing anything vis a vis current practice.
>> On Apr 15, 2016, at 11:12 AM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
>> I should have commented earlier, but I think we have an issue with the following:
>> In section 7, insert the following introduction paragraph:
>> "All Certificates and Certificate Revocation Lists SHALL comply with RFC 5280 and RFC 6818. They SHALL additionally comply with RFC3279, RFC4055, RFC5480, RFC5756, RFC5758 as appropriate based on the Subject Public Key Info and the Signature Algorithm present in the certificate."
>> There is at least one clear instance where the CAB Forum BRs aren't necessarily inline with these docs - ie returning "revoked" instead of "good".
>> Therefore, DigiCert votes "No".
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Peter Bowen
>> Sent: Friday, April 15, 2016 9:59 AM
>> To: CABFPub
>> Subject: Re: [cabfpub] Ballot 167 - Baseline Requirements Corrections
>> Amazon votes YES.
>>> On Apr 7, 2016, at 5:56 PM, Peter Bowen <pzb at amzn.com> wrote:
>>> <CA-Browser Forum BR 1.3.3-corrections.4.doc>
>>> I have removed the heading change for section 126.96.36.199. A redlined version of the BRs is attached for those wishing to review in that format. With that:
>>> Ballot 167 review period is starting. Assuming no more changes and that the ISRG re-confirms endorsement, voting should start in one week.
>>>> Ballot 167: Baseline Requirements Corrections
>>>> The following motion has been proposed by Peter Bowen of Amazon and endorsed by Dimitris Zacharopoulos of HARICA and Josh Aas of ISRG:
>>>> A number of small corrections and clarifications to the Baseline Requirements have been identified. These are, in general, changes that reflect the existing understanding of the Baseline Requirements by the Forum. Due to the understanding that these primarily represent existing practice, they are combined for efficiency.
>>>> -- MOTION BEGINS --
>>>> Effective the date of passage, the following modifications to the Baseline Requirements are adopted:
>>>> In Section 1.6.1:
>>>> - In the definition of "Country", replace "sovereign nation" with "Sovereign State";
>>>> In Section 1.6.3:
>>>> - Delete RFC2560;
>>>> - Insert "RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013.";
>>>> - Delete X.509v3;
>>>> - Insert "X.509, Recommendation ITU-T X.509 (10/2012) | ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks."
>>>> Move the content in section 3.3.1 to section 4.2.1 to become the third paragraph in 4.2.1 and leave section 3.3.1 blank.
>>>> In section 4.9.9, replace all occurrences of "RFC2560" with "RFC6960".
>>>> In section 5.2.2, insert "CA" immediately before "Private Key".
>>>> In section 6.1.2, append "without authorization by the Subscriber" to the end of the first sentence.
>>>> In section 6.1.6, update the last citation to read: "[Source: Sections 188.8.131.52.2 and 184.108.40.206.3, respectively, of NIST SP 56A: Revision 2]"
>>>> In section 6.2, in the second sentence, insert "CA" immediately before both instances of "Private Key".
>>>> In section 6.2.5, append "without authorization by the Subordinate CA" to the end of the sentence.
>>>> In section 7, insert the following introduction paragraph:
>>>> "All Certificates and Certificate Revocation Lists SHALL comply with RFC 5280 and RFC 6818. They SHALL additionally comply with RFC3279, RFC4055, RFC5480, RFC5756, RFC5758 as appropriate based on the Subject Public Key Info and the Signature Algorithm present in the certificate."
>>>> In sections 220.127.116.11(e) and 18.104.22.168(h) change the organizationName line to read:
>>>> "- organizationName (OID 22.214.171.124): This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 126.96.36.199. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”."
>>>> Replace "Subordiate" with "Subordinate" in the title of 188.8.131.52.
>>>> In section 9.6.1 item 6:
>>>> - Insert "are the same entity or" immediately prior to "are Affiliated";
>>>> - Remove "and accepted".
>>>> In section 9.6.3 item 2, replace "maintain sole control" with "assure control".
>>>> - Section 1.6.1, in the definition of "Subscriber"
>>>> - Section 4.1.2
>>>> - Section 184.108.40.206
>>>> - Section 4.9.11
>>>> - Section 9.6.1
>>>> - Section 9.6.3
>>>> -- MOTION ENDS --
>>>> The review period for this ballot shall commence at 2200 UTC on 7 April 2016, and will close at 2200 UTC on 14 April 2016. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 21 April 2016. Votes must be cast by posting an on-list reply to this thread.
>>>> A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/
>>> Public mailing list
>>> Public at cabforum.org
>> Public mailing list
>> Public at cabforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4964 bytes
Desc: not available
More information about the Public