I previously pointed out that “The Age of Certificate Data” section was
“inadvertently” moved to be under “3.3.1 Identification and Authentication for
Routine Re-key” when we reformatted the document. This seems inaccurate.
Ryan recommended moving it to section 4.2.1, between the paragraphs "Applicant
information MUST" and "The CA SHALL develop", which looks to be the right
place. I doubt this would be controversial and is just the movement of one
paragraph from one section to another. Maybe you can consider this change in
the next clean-up ballot?
Doug
From: [email protected] [mailto:[email protected]] On
Behalf Of Stephen Davidson
Sent: Thursday, March 17, 2016 11:42 AM
To: [email protected]; Dean Coclin <[email protected]>; CABFPub
<[email protected]>
Subject: Re: [cabfpub] Pre-ballot on membership requirement update
The wildcard clarification is one; and I don’t think it’s controversial.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Thursday, March 17, 2016 12:38 PM
To: Dean Coclin <[email protected]<mailto:[email protected]>>;
CABFPub <[email protected]<mailto:[email protected]>>
Subject: Re: [cabfpub] Pre-ballot on membership requirement update
Dean, Trend Micro will endorse. But can we combine with some of the other
non-controversial BR changes that have been circulating (I can’t remember what
they are) in a “miscellaneous” ballot?
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Dean Coclin
Sent: Thursday, March 17, 2016 8:29 AM
To: CABFPub
Subject: [cabfpub] Pre-ballot on membership requirement update
I am looking for 2 endorsers for the following:
Background:
Section 2.1 (a)(1) says that Issuing CAs “actively issue certificates to Web
servers…”
Section 2.1(b) of the bylaws lists the items needed in a membership application
by CAs.
But that section does not ask the CA applicant to provide a 3rd party website
where the CA/B Forum can validate that they are actively issuing certs to web
servers. We do however ask the applicant this question, after they have
submitted their application. It would be helpful to have this in the bylaws so
we don’t have to go back and ask every time.
Specific change:
Add under 2.1(b)
(7) The URL of at least one third party website that is using a certificate
from the applicant’s CA which can be examined by Forum members
Thanks,
Dean
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.
--- Begin Message ---
Based on https://tools.ietf.org/html/rfc3647#section-4.4.2 , it would seem like
Section 4.2.1 might be more appropriate.
If I'm understanding correctly, the goal of Section 3.3 is to describe how data
is initially validated/processed. I don't think adding a Section 3.5 is
consistent with our goals of a 3647 framework.
For example, perhaps moving it to section 4.2.1, between "Applicant information
MUST" and "The CA SHALL develop"
The CA MUST ensure that that all data and documents validated according to
Section 3.2 was provided to the CA no more than thirty-nine (39) months prior
to issuing the Certificate.
I'm not sure whether we want to "provided to the CA" or "obtained by the CA",
and if CAs feel there's a distinction worth making.
This would also, hopefully, encompass the activities of the RA with respect to
the final paragraph of Section 4.2.1 - that is, if documents were provided (and
validated) by an RA, then they are "fulfilling [any of] the CA's obligation
under this section", and thus the 39-month period applies to the RA, not when
the RA submitted the validated docs to the CA. I believe that's consistent both
with the original 11.3 and with the intent, but I'd be curious if others
disagree.
On Thu, Dec 3, 2015 at 4:35 AM, Doug Beattie
<[email protected]<mailto:[email protected]>> wrote:
I might have mentioned this before but ran across it again today. Prior to
RFC 3647 format conversion we had this:
11.3 Age of Certificate Data
Section 9.4 limits the validity period of Subscriber Certificates. The CA
MAY use the documents and data provided in Section 11 to verify certificate
information, provide that the CA obtained the data or document from a source
specified under Section 11 no more than thirty-nine (39) months prior to
issuing the Certificate.
But now we have this:
3.3 Identification and authentication for re-key requests
3.3.1 Identification and Authentication for Routine Re-key
Section 6.3.2 limits the validity period of Subscriber Certificates. The
CA MAY use the documents and data provided in Section 3.2 to verify certificate
information, provided that the CA obtained the data or document from a source
specified under Section 3.2 no more than thirty-nine (39) months prior to
issuing the Certificate.
The re-use of certificate data seems to be limited to routine Re-key
requests when before it could be used for any purpose. Can we find a new
heading section for this so it’s clear we can use it for purposes other than
rekey? Maybe a new section, 3.5, for this purpose?
_______________________________________________
Public mailing list
[email protected]<mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
--- End Message ---
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
