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

Thu Nov 13 21:13:32 UTC 2014

Jeremy,

If the extent of Gerv's proposal is that it has to disappear off into a
research group, what are your feelings for my proposal, which is to clarify
that it IS in scope for a BR audit?

On Thu, Nov 13, 2014 at 1:10 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
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> 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> 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> 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
>
> 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/20141113/f3d245a0/attachment-0003.html>