[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Thu Nov 13 14:35:07 MST 2014

No concern left, Jeremy.
If no EKU, anyPolicy intermediates pass audit, so no need re-issue them, 
this is fine.

Thinks,
M.D.

On 11/13/2014 11:10 PM, Jeremy Rowley wrote:
>
> The SHA-1/1024 bit issue is a good point. However, it's easier to 
> impose new requirements on EE certs than an intermediate, meaning I'd 
> be more cautious in the change.  I'm in favor of the proposal, but a 
> year might be a little short if we're dealing with multiple standards 
> bodies.
>
> I'm also not aware of which bodies this might affect.  I think we 
> should ask the various groups and see if any intermediate could not 
> comply with both the BRs and their policies.  That way we have actual 
> factual basis for discussion rather than speculation. I'll reach out 
> to my contacts and report back as soon as possible.  If others could 
> do the same, it'd be appreciated.
>
> Moudrick -- you mentioned this is a concern?  Do you know what bodies 
> this might create a problem for and why?
>
> Jeremy
>
> *From:*Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Thursday, November 13, 2014 2:03 PM
> *To:* Jeremy Rowley
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] (Eventually) requiring id-kpServerAuth for 
> all certs in the chain?
>
> If these groups are requiring that it MUST NOT appear in 
> intermediates, then they're defining a profile atop RFC 5280, right? 
> So it's not that it's an RFC 5280 issue, but a broader issue with 
> whatever other specification.
>
> If it were that some group required EE certs MUST be RSA 1024-bit, or 
> MUST use SHA-1, would we have the same concern? I recall some for the 
> former (ironically, in the payment industry, which is all sorts of 
> depressing), less so for the latter, but in either case, this seems to 
> highlight a fundamental issue with CAs trying to use the same root to 
> be audited to multiple standards - at some point, you must be prepared 
> for the standards to diverge.
>
> There are plenty of ways to mitigate those risks (as has been 
> discussed in the past), but is it a Forum issue or a 
> CA-using-the-same-root-for-different-things issue?
>
> On Thu, Nov 13, 2014 at 12:59 PM, Jeremy.Rowley 
> <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>> wrote:
>
> I realize it's not normative and it's not really a concern for us - 
> more of an observation that requiring an EKU in intermediates is 
> opposite of the text in the RFC.  The issue is not that we'd break 
> those other groups but that we'd force their intermediates to comply 
> with the BRs, which might not be possible for some groups.
>
> Jeremy
>
> On 11/13/2014 1:45 PM, Ryan Sleevi wrote:
>
>     Jeremy,
>
>     that language is hardly normative, nor are there normative
>     restrictions on it, nor would it adversely affect the algorithm of
>     RFC 5280 Section 6 (and indeed, if someone was enforcing that CAs
>     not have the EKU, they'd be violating Section 6.1 para3)
>
>         While the algorithm could be extended to include checks for
>         conformance to the profiles in Sections 4 and 5, this profile
>         RECOMMENDS against including such checks.
>
>     So I'm not sure I fully understand your concern.
>
>     On Thu, Nov 13, 2014 at 12:40 PM, Jeremy.Rowley
>     <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>>
>     wrote:
>
>     Doesn't all this ignore 5280's recommendation that "In general,
>     this extension will appear only in end entity certificates"?
>     Ignoring this might put browsers at odds with other industry
>     groups also using PKI.
>
>
>
>
>     On 11/5/2014 2:31 PM, Brian Smith wrote:
>
>         Gerv,
>
>         Please note that Ryan and I appear to be suggesting exactly
>         the same thing. And, note that what I'm suggesting here is
>         exactly the same argument I made for interpreting EKU in
>         end-entity certificates earlier this year or last year: a lack
>         of EKU is equivalent to "anyExtendedKeyUsage". This is what
>         all (AFAICT) certificate verification code does today.
>
>         Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org>>
>         wrote:
>
>         > However, I'm assuming that for the CAs for which the BRs
>         apply, it is
>         > already the case that all or most of their intermediates
>         conform to the
>         > BRs.
>
>         I would hope so. But is it programmatically detectable that
>         they do? If
>         so, how? "Publicly audited" is not a determinable
>         characteristic of an
>         intermediate.
>
>         Your proposal has the same issue. In both proposals, just by
>         looking at the certificate chain, you can tell whether the
>         intermediate is required to conform to the BRs or not. The
>         only difference is that the way Ryan and I are suggesting
>         already matches what Chrome (on Windows, at lesat), IE, and
>         Firefox are already doing, whereas you are proposing that all
>         browsers eventually (5-10 years from now?) be changed to do
>         something new, without any protection for users until then.
>
>             Also, your proposal 1) requires a re-issue of
>             intermediates for all
>             private PKIs, right? Because they all need to have EKUs in
>             them?
>
>         If a CA certificate chains to a root for which the BRs apply,
>         and that sub-CA doesn't want to be held to the BRs (ostensibly
>         because they don't intend to issue SSL certificates), then
>         they would need to have their sub-CA cert re-issued (and the
>         old one revoked) with an EKU extension that does not include
>         id-kp-serverAuth or anyExtendedKeyUsage, unless their
>         certificate already has such an EKU. That is the only
>         situation in which re-issuance would be necessary.
>
>         If private CAs don't issue SSL certificates, then it would be
>         a good idea to replace their CA certificates with ones that
>         contain an EKU that doesn't have id-kp-serverAuth or
>         anyExtendedKeyUsage, to follow the principle of least
>         privilege. But, they wouldn't be required to make any change,
>         because the BRs don't apply to them, assuming that they don't
>         chain to a trusted root. If they do chain to a trusted root
>         then they're not private and the above paragraph applies.
>
>         Cheers,
>
>         Brian
>
>         _______________________________________________
>
>         Public mailing list
>
>         Public at cabforum.org  <mailto:Public at cabforum.org>
>
>         https://cabforum.org/mailman/listinfo/public
>
>
>     _______________________________________________
>     Public mailing list
>     Public at cabforum.org <mailto: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: https://cabforum.org/pipermail/public/attachments/20141113/7c9df0fe/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3653 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20141113/7c9df0fe/attachment-0001.bin 