On 02/03/2017 00:59, Ryan Sleevi wrote:
On Wed, Mar 1, 2017 at 12:12 PM, douglas.beattie--- via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
On Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote:
Would it be possible to get a more precise answer other than "in
accordance with"? I am left to assume that in fact no verification was
performed because the previous verification was in the 39 month window.
For this SSL product, customers place orders which are vetted to the OV
level with normally just a single SAN. Once the order has been approved
they can add SANs by verifying domain control via DNS or File based
verificaton options. Over time they add and remove SANs as their customer
base changes. They can re-issue the certificate which keeps the expiration
date and the subject DN the same, but they add and remove SANs.
In this case they did not remove SAN which are clearly not functional and
are for domains which have expired. The reissueance process does not
require the re-verification of the domain control, thus the certificate was
reissued with these SANs.
Subscribers are required to tell us when the certificate contents is
no-longer accurate so appropriate action can be taken, but clearly this
customer did not inform us. We'll be talking with them about this to find
out why.
Doug,
A few follow-ups:
This description is somewhat concerning in its omission - namely, whether
or not GlobalSign revalidates this information on the 39 month period
required by the Baseline Requirements.
Q1) Can you confirm that this system ensures that all domains are
revalidated if the validation occurred more than 39 months prior, as per
the Baseline Requirements, v1.4.2, Section 4.2.1
I read his previous answer as saying that the system will in no case
extend the validity of a validation beyond the duration of the
certificate in which it was originally listed (that duration being
clearly visible in the certificates in question).
The only corner cases seemingly not answered are these:
Does GlobalSign allow (for this product) that initial inclusion of a SAN
within a subscription period to be accepted based on a previous
validation occurring more than 39 months before the last permitted
certificate reissuance with added/removed SANs?
Does GlobalSign allow other certificate products that can be freely
reissued within their validity period to be based on validation data
that could exceed the 39 month age limit before the certificate and its
reissuance option expires?
Conversely there are questions about what the BRs requires in such
corner cases:
Do the BRs require the 39 month age limit to be satisfied when a
certificate is reissued with unchanged subject data and expiry date,
(but with new serial and public key), thus expiring less than the BR
permitted maximum validity duration after an original issuance date
within that 39 month limit?
If the BRs do not require that, do they require this if a certificate
is reissued with unchanged expiry date and unchanged data for the
subject in question, but with changes for other subjects?
Q2) If, in the process of confirming a, deficiencies are noted in the
enforcement of this, can you provide details as to how many certificates
this issue might affect?
The Baseline Requirements, v1.4.2, Section 9.6.3 details obligations with
respect to the Subscriber Agreements that CAs SHALL require. As part of
this, Item 5, (b) notes that the Subscriber Agreement includes "An
obligation and warranty to: ... (b) promptly request revocation of the
Certificate, and cease using it, if any information in the Certificate is
or becomes incorrect or inaccurate." Per Section 4.9.1.1 of the Baseline
Requirements, "The CA SHALL revoke a Certificate within 24 hours if one or
more of the following occurs:" ... "The CA is made aware that a Subscriber
has violated one or more of its material obligations under the Subscriber
Agreement or Terms of Use".
Given that GlobalSign has acknowledged that the Subscriber has failed to
abide by the required Subscriber Agreement, and given that GlobalSign
acknowledged this at Tue, 28 Feb 2017 04:46:25 -0800 (PST), it would appear
that this certificate is not revoked, however, my attempts at confirming
with your OCSP server seem to at least produce issues on the several
Windows devices I tried.
That's a bit harsh on the subscriber (for a simple failure to notify),
but probably within the legal requirements of the BRs.
Q3) Can you confirm that this certificate (and all related certificates)
are revoked, as per Section 4.9.1.1 of the Baseline Requirements?
Q4) Can you confirm that your OCSP responder is properly available? For
your ease of diagnostic, the Windows command is "certutil -f -urlfetch
-verify [certificatefile]", which other CAs' revoked and unrevoked
certificates are working fine with.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
