[cabfpub] [cabfman] Update of Yngve's BR 1.1 issues + #10
Rick Andrews
Rick_Andrews at symantec.com
Thu May 24 17:20:22 MST 2012
Yngve,
(Moving to public list)
Where can I find the list of BR 1.1 issues? I see this on the wiki (https://www.cabforum.org/wiki/Baseline%20Requirements%20for%20the%20Issuance%20and%20Management%20of%20SSL%20Certificates%20Version%201.1?action=AttachFile&do=view&target=Draft+01.doc) but it's just a subset of the BR document, not a list of issues.
I don't agree with one of your rationales: "Make sure an unknown certificate cannot get OK revocation status". I agree that RFC2560 says that "OK" is an acceptable response in this case, but RFC5019 says that a status of "unauthorized" should be returned in this case. Do you object to "unauthorized" because it's an unsigned response?
Finally, you suggest adding this:
(3) The CA obtains evidence that the Subscriber’s Private Key (corresponding
to the Public Key in the Certificate) has suffered a Key Compromise, or that
the Certificate has otherwise been misused (also see Section 10.2.4); or the
public key no longer complies with requirements of Appendix A. A Private Key
is presumed to be compromised if methods have been developed that can easily
calculate it based on the Public Key (such as a Debian weak key, see
http://wiki.debian.org/SSLkeys), or if there is evidence that the method
used to generate the Private Key was flawed (such as presented in
https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/).
I don't see the value in adding this language. CAs now know how to check for duplicate keys or keys with common factors, but such checks are only as good as the size of the data set it's checking against. Can a small CA just check against other keys in its db? Or must it get the EFF data and compare against that? This seems unenforceable to me.
-Rick
-----Original Message-----
From: management-bounces at cabforum.org [mailto:management-bounces at cabforum.org] On Behalf Of Yngve Nysaeter Pettersen
Sent: Thursday, May 24, 2012 6:43 AM
To: management at cabforum.org
Subject: Re: [cabfman] Update of Yngve's BR 1.1 issues + #10
Hello all,
Below is the suggested errata motion that should resolve BR 1.1 issues #5,
#6, #7, #8, #10, and #21 (#16 was superseded by #15)
I am seeking two endorsers.
To recap, the rationale for these changes (discussed in greater detail in
my emails of Feb 5 and April 17) is to:
- make requirements for revocation (info and actions) stronger or clearer
- Make sure an unknown certificate cannot get OK revocation status
- Document good practice regarding public keys.
- Make it clear that methods that can easily calculate a key or group of
keys constitute key compromise and must lead to immediate revocation upon
discovery.
- Make sure that Subordinate CA certificates are held to the same
standard as normal certificates.
.... Motion begins ....
Effective July 1, 2012
Erratum begins:
A. At start of section 13.1.5 (Reasons for Revocation) delete current text
The CA SHALL revoke a Certificate within 24 hours if one or more of the
following occurs:
and insert:
The CA SHALL revoke a Subscriber Certificate or Subordinate CA
Certificate
within 24 hours of obtaining confirmation if one or more of the
following occurs:"
B. In section 13.1.5 delete point (3) and insert:
(3) The CA obtains evidence that the Subscriber’s Private Key
(corresponding
to the Public Key in the Certificate) has suffered a Key Compromise, or
that
the Certificate has otherwise been misused (also see Section 10.2.4);
or the
public key no longer complies with requirements of Appendix A. A Private
Key
is presumed to be compromised if methods have been developed that can
easily
calculate it based on the Public Key (such as a Debian weak key, see
http://wiki.debian.org/SSLkeys), or if there is evidence that the method
used to generate the Private Key was flawed (such as presented in
https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/
).
C. In section 13.1.5 (Reasons for Revocation) insert before current point
10 new points 10 and 11, incrementing current point 10 and succeeding
points by 2:
10. The Subordinate CA ceases operations for any reason and has not
made
arrangements for another CA to provide revocation support for the
Certificate;
11. The Subordinate CA’s right to issue Certificates under these
Requirements expires or is revoked or terminated, unless the
Subordinate CA
has made arrangements to continue maintaining the CRL/OCSP Repository;
D. In section 13.2 insert new section 13.2.6:
13.2.6 Suspension of certificates
The Repository MUST NOT include entries that indicate that the
certificate is suspended.
E. In section 13.2 insert new section 13.2.7 with text:
13.2.7 Response for non-issued certificates
If the OCSP responder receives a request for status of a certificate
that
has not yet been issued, then the responder MUST respond with a
"REVOKED"
status. The CA MUST monitor the responder for such requests as part of
its security response procedures.
F. In Appendix A add after table (3):
(4) General requirements for public keys:
RSA: The value of the public exponent MUST be 3 or larger, 65537 is
RECOMMENDED
G. In Appendix B "Subordinate CA" remove point C
(authorityInformationAccess) and insert
C. authorityInformationAccess
This extension MUST be present. It MUST NOT be marked critical,
and it MUST contain:
* the HTTP URL of the Issuing CA’s OCSP responder (accessMethod =
1.3.6.1.5.5.7.48.1). See Section 13.2.1 for details about OCSP
revocation
requirements.
* the HTTP URL where a copy of the Issuing (non-Root) CA’s
certificate (accessMethod = 1.3.6.1.5.5.7.48.2) can be downloaded
from a 24x7 online repository.
H. In Appendix B "Subscriber Certificate" remove point C
(authorityInformationAccess) and insert
C. authorityInformationAccess
This extension MUST be present. It MUST NOT be marked critical,
and it MUST contain:
* the HTTP URL of the Issuing CA’s OCSP responder (accessMethod =
1.3.6.1.5.5.7.48.1). See Section 13.2.1 for details about OCSP
revocation
requirements.
* the HTTP URL where a copy of the Issuing CA’s certificate
(accessMethod = 1.3.6.1.5.5.7.48.2) can be downloaded
from a 24x7 online repository.
Erratum ends
.... Motion ends .....
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve at opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 23 69 32 60 Fax: +47 23 69 24 01
********************************************************************
_______________________________________________
Management mailing list
Management at cabforum.org
http://cabforum.org/mailman/listinfo/management
More information about the Public
mailing list