[cabfpub] Must Staple and BR Issue 7
ben at digicert.com
Mon Nov 5 14:40:51 UTC 2012
As an extension and not a key usage is fine, too.
From: Ben Wilson [mailto:ben at digicert.com]
Sent: Monday, November 05, 2012 7:38 AM
Subject: RE: [cabfpub] Must Staple and BR Issue 7
1) I can't see anything that would break, unless it is improperly coded
in relying party software.
2) I didn't think that this must-staple extension needed to be
implemented for the chain, unless for some reason with multi-stapling
3) CAs could provide the subscriber with two alternative EE
certificates (one with and one without the EKU)
4) I can't see the benefit of "must-staple" in an intermediate
From: Phillip Hallam-Baker [mailto:hallam at gmail.com]
Sent: Monday, November 05, 2012 7:02 AM
To: Adam Langley
Cc: Ben Wilson; Paul Tiemann; CABFPub
Subject: Re: [cabfpub] Must Staple and BR Issue 7
We really have to avoid key usage if it is going to mean scoping.
The issues I see wrt encoding are:
1) Backwards compatibility, will it break anything?
2) Scope of impact, does anything have to be changed other than the EE cert
3) Reliability, can browsers be confident that the must staple extension
will only be present when the server is configured to support it
4) Forwards compatibility, will we have to do a redo if TLS multi stapling
requires a different approach?
On Mon, Nov 5, 2012 at 7:46 AM, Adam Langley <agl at google.com> wrote:
On Sun, Nov 4, 2012 at 5:32 PM, Ben Wilson <ben at digicert.com> wrote:
> If we were to revise Appendix B of the Baseline Requirements, as outlined
> the proposed ballot to address BR Issue #7 (relined version attached, but
> not fully endorsed yet for vote), would it make sense to amend section F
> Subscriber Certificates (extKeyUsage) (which currently says, "Either the
> value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both
> values MUST be present. id-kp-emailProtection [RFC5280] MAY be present")
> also say that, in addition emailProtection, the CABF extKeyUsage OID for
> must-staple (184.108.40.206.1) MAY be present? (Even if it had to be
> as its own separate ballot because it is not in direct response to the BR
> Issue#7? Or is it substantially related enough?) After reviewing this
> attachment, are there any endorsers, or persons who would endorse if
> modifications were made?
I thought we figured that it was going to be an extension, not a
keyUsage? The keyUsage was easier for some CAs to issue, but the
feeling that I got was that people didn't like overloading the
meaning. There's also that problem that keyUsage, in reality, is
defined as a scope down the chain. (i.e. that the keyUsage would have
to be permitted all the way to the root.)
Public mailing list
Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public