[cabfpub] Ballot 103 - OCSP Staping and AIA (DRAFT)

Sat May 25 00:44:40 UTC 2013

I don't want everyone spending time not focused on getting this issue
resolved.  I've removed "errata" from the title of the ballot and replaced
"list of errata" with "list of amendments" so that we can get down to
business.  Now, could everyone take a look at the redlined PDF I circulated
and please provide feedback on whether any other items need to be changed
before this is placed on the 14-day review-and-vote track.

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Friday, May 24, 2013 6:25 PM
To: ben at digicert.com
Cc: kirk_hall at trendmicro.com; CABFPub
Subject: Re: [cabfpub] Ballot 103 - OCSP Staping and AIA Errata (DRAFT)

On Fri, May 24, 2013 at 5:19 PM, Ben Wilson <ben at digicert.com> wrote:

I am thinking this as errata - it was a mistake in language from the start
because servers can't do OCSP stapling unless they can look at the AIA for
the OCSP in certificate.  To say that with OCSP stapling you don't need an
AIA was clearly a mistake.

As I expressed on previous calls, this is not accurate. It's entirely
possible to configure the AIA for the associated server certificate using
some out-of-band configuration mechanism.

The current language permits this, and through the use of the contractual
language, allows CAs to omit such information from the certificate.

Our past calls and minutes established this as a "Harder for customers to
make misconfiguration" feature, rather than "Impossible to use correctly",
which you seem to be suggesting.

While I can certainly see some motivation, particularly for clients that do
not support stapling, I definitely see this as a change in meaning/intent,
and have to agree with Kirk that this takes the form of an amendment, if we
want to quibble on that vs errata :)

Cheers,

Ryan

From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] 
Sent: Friday, May 24, 2013 6:11 PM
To: ben at digicert.com; public at cabforum.org
Subject: RE: [cabfpub] Ballot 103 - OCSP Staping and AIA Errata (DRAFT)

Ben - does this really address errors (errata), or is it simply an amendment
to our existing standards?  If the latter, can we start re-naming these
motions as simple "Amendments"?

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Friday, May 24, 2013 5:08 PM
To: public at cabforum.org
Subject: [cabfpub] Ballot 103 - OCSP Staping and AIA Errata (DRAFT)

This is a Draft Ballot to address BR Issue 7.  I've reworked it since our
last discussion, and I'm looking for endorsers.  One question that we need
to resolve is whether (5) below is premature.  It states, "The certificate
MAY contain the TLS Feature Extension advertising that the status_request
feature of OCSP stapling is available and supported by the subscriber."
(Must staple)    If premature, then subsection (5) of the motion can be
deleted.  However, if we think we can address this now, then we can leave it
in.  Eventually whether we use IETF OIDs or our own CABF OIDs, (we've said
that must-staple was going to have the OID of 2.23.140.16.1), any numbers
could be added in later as parentheticals.  A redlined PDF of the proposal
is attached.

Ballot 103 OCSP Stapling and AIA

Ben Wilson of DigiCert made the following motion, and ____ from _____  and
______ from ______ endorsed it:

---Motion Begins ---

EFFECTIVE IMMEDIATELY, in order to correct erroneous statements concerning
the allowance of stapling in section 13.2.1 and the requirement for an
authorityInformationaccess (AIA) uniform resource identifier for OCSP
responders in Appendix B of the Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates, we propose the following
amendments:

---List of amendments begins---

(1)  In Section 13.2.1 "Mechanisms" DELETE the first clause in the second
paragraph "If the Subscriber Certificate is for a high-traffic FQDN,so that
as amended the section reads as follows:

"13.2.1  Mechanisms

The CA SHALL make revocation information for Subordinate Certificates and
Subscriber Certificates available in accordance with Appendix B.

The CA MAY rely on stapling, in accordance with [RFC4366], to distribute its
OCSP responses.  In this case, the CA SHALL ensure that the Subscriber
"staples" the OCSP response for the Certificate in its TLS handshake.  The
CA SHALL enforce this requirement on the Subscriber either contractually,
through the Subscriber or Terms of Use Agreement, or by technical review
measures implement by the CA."

(2)  In Appendix B "2. Subordinate CA 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 stapling requirements.

Certificates that are not issued by a Root CA SHOULD contain an AIA with 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.

(3)  In Appendix B "3. 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). 

Subscriber Certificates SHOULD contain an AIA with 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.

(4)  In Appendix B "3. Subscriber Certificate" remove point D
(basicConstraints) and insert:

D.  basicConstraints (optional)

If present, this field MUST be marked critical and the cA field MUST be set
to false.

(5)  In Appendix B "3. Subscriber Certificate" after point F insert a new
point G (TLS Feature Extension) as follows:

G.  TLS Feature Extension (optional)

Subscriber Certificates MAY contain the TLS Feature Extension advertising
that the status_request feature of OCSP stapling is available and supported
by the subscriber.  If present, this field MUST NOT be marked critical. 

=====Motion Ends=====

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail
or
telephone and delete the original message from your mail system.

_______________________________________________
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/20130524/e3516db8/attachment-0002.html>