[cabfpub] To revoke or not to revoke 1024

Tue Jun 25 02:47:52 UTC 2013

It was pointed out to me that my response regarding code signing certs 
was not clear.

I think it's fine for 1024-bit code signing certs to expire, and not be 
revoked based on some transition date. I think that 1024-bit code 
signing certs should not be used to sign new code after this year.

Kathleen

On 6/24/13 3:31 PM, Kathleen Wilson wrote:
> Rick,
>
>> Please comment, especially browser vendors.
>
> Mozilla's wiki page about this 
> (https://wiki.mozilla.org/CA:MD5and1024) was created in April 2010, 
> and email about it was also sent to CAs 
> (https://wiki.mozilla.org/CA:Communications#October_11.2C_2010)
>
> The wiki page allows for use of 1024-bit certs when needed for 
> interoperability reasons:
> "- This means that CAs should only consider issuing a 1024-bit 
> certificate if it is requested and justified by the subscriber for a 
> specific reason, such as interoperability with devices that do not yet 
> support certificates with larger key sizes.
> - The CA must assess the risk involved in issuing such a certificate 
> for legacy use/interoperability, and determine if they are willing to 
> accept the risk, as well as any possible liability. The subject and 
> relying parties also need to determine if they will accept any risks 
> and liabilities."
>
> The wiki page also makes it clear that CAs should not expect continued 
> support of 1024-bit certs in Mozilla products:
> "Under no circumstances should any party expect continued support for 
> RSA key size smaller than 2048 bits past December 31, 2013."
>
>
>> Do CAs need to revoke 1024-bit end-entity certs by the end of 2013?
>
> I think that depends on the type of cert and when it expires.
>
> I am fine with S/MIME certs being transitioned whenever they expire, 
> even if it is a couple of years out. Though, I won't guarantee support 
> of those certs in Mozilla products.
>
> I would like to see the transition from 1024-bit SSL and code signing 
> certs happen soon. However, it really doesn't matter to me what the 
> exact date is, as long as the transition is completed before it 
> becomes an emergency.
>
> Also on the wiki page: "December 31, 2013 -- Mozilla will disable the 
> SSL and Code Signing trust bits for root certificates with RSA key 
> sizes smaller than 2048 bits. If those root certificates are no longer 
> needed for S/MIME, then Mozilla will remove them from NSS."
>
> In hindsight, I should have said "after December 31...". My goal is Q1 
> 2014, and I am working on this in Mozilla Bugzilla #881553.
>
>> Since the BRs effectively cover only certs issued after "the 
>> effective date", does that mean that certs issued before "the 
>> effective date" don't need to be revoked?
>
> That was my interpretation of the BRs, but Mozilla's communication 
> about phasing out 1024-bit certs started in 2010. In 2010 I also 
> exchanged direct email with representatives of the CAs that had 
> 1024-bit root certs included in Mozilla products at that time, so all 
> impacted CAs were well aware of Mozilla's requirements.
>
>> What about code signing certs?
>
> What I said above applies to both SSL and code signing certs.
>
>
> Kathleen
>
>
>
> On 6/23/13 12:32 PM, Rick Andrews wrote:
>> We discussed this a bit in our face-to-face meeting in Munich, but 
>> did not reach consensus. I'd like to continue the conversation with 
>> all via the list.
>> Putting aside the question of "web pki" vs. "non-web pki", Symantec 
>> and other CAs would like to see if we can achieve consensus on these 
>> questions:
>>
>>  1. Do CAs need to revoke 1024-bit end-entity certs by the end of 2013?
>>
>>  1. I believe that some CAs believed that revoking such certs was
>>     mandatory. However, I see no hard evidence of that.
>>  2. The BRs say that 1024-bit can be issued as long as the end date
>>     is before December 31, 2013. Others have said that a CA that was
>>     compliant with the BRs would not have issued a 1024-bit end
>>     entity cert after the effective date if its end date was 2014 or
>>     later. However, we've seen that not all CAs became compliant on
>>     July 1, 2012. Given what we now know about audits and effective
>>     dates, it seems to me that there is a lot of uncertainty here.
>>  3. Apart from the BRs, CAs have to consider browser policy which may
>>     go above and beyond the BRs. In a private conversation with Tom
>>     Albertson of Microsoft, he told me that "Our policy doesn't
>>     contemplate CAs revoking EE certs issued before 1 Jan 2014,
>>     unless or until an RSA factoring attack is imminent, and we all
>>     go into response mode." Mozilla's policy seems to be similar --
>>     it says that such certs must expire by January 1, 2014, but it
>>     does not mandate that CAs revoke any such certs that would live
>>     beyond that date.
>>  4. If there is no clear direction here, I propose that CAs simply
>>     let all 1024-bit end entity certs expire naturally, as long as
>>     the CA has stopped issuing 1024-bit end entity certs, and made an
>>     honest effort to comply with the BRs (hard to define, but at the
>>     very least would mean that the CA wasn't still issuing multi-year
>>     1024-bit certs in 2013).
>>
>>  2. Since the BRs effectively cover only certs issued after "the
>>     effective date", does that mean that certs issued before "the
>>     effective date" don't need to be revoked?
>>
>>  5. That is my interpretation. Given what I said in 1) above, even
>>     those certs issued after the effective date don't need to be
>>     revoked, unless some browser's policy mandates that action.
>>
>>  3. What about code signing certs?
>>
>>  6. The BRs don't cover non-EV code signing certs, so again this goes
>>     back to browser policy. And unless some browser comes forth with
>>     unambiguous policy on code signing certs, I would suggest they
>>     are also off the table (do not need to be revoked).
>>
>> Please comment, especially browser vendors. Thanks,
>> -Rick
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130624/afcdae95/attachment-0003.html>