On 03/03/2017 06:44, Ryan Sleevi wrote:
Hi Jakob,
On Thu, Mar 2, 2017 at 9:14 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
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).
For the avoidance of doubt or confusion, I suspect it would be best for
Doug to be able to answer the questions posed to Doug :)
Of cause, I was trying to help the process along by separating that
which seems obvious from previous answers (but might need trivial
confirmation) from that which remains truly open questions.
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?
I'm having trouble understanding what you're asking here. While I may be
the only one confused, perhaps you can reword this question?
Suppose that at T1=x, a subscriber to this GlobalSign product obtained
a certificate with lifertime L=y, with permission to add/remove from
the list of included SANs until T3=x+y, each time keeping the cert
expiry value at T3=x+y. (This is what GlobalSign described in their
previous answer).
Suppose also, that when such updates are done at T2 < x+y, GlobalSign
does not revalidate those SANs that are not changed at time T2 (this
also seems to be what GlobalSign described in their previous answer,
but is less clear).
Now does GlobalSign ensure, at time T1=x that the validation data that
can be thus reused until time T3=x+y was obtained on or after T0=x+y-39,
thereby ensuring that it will be less than 39 months old at any time T2
permitted by the above assumptions?
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?
This is a similar question which I personally find confusingly worded, so
perhaps you can expand.
A number of GlobalSign's certificate products (perhaps most of them)
allow the certificate holder to request a reissuance with a new public
key and serial number at any time until expiry.
Question is if GlobalSign ensures that the validation data used at
issuance time T1=x with lifetime/reissuance permission L=y was obtained
on or after T0=x+y-39, as is required according to your interpretation
of the BRs.
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?
The Baseline Requirements do not define reissue. Every certificate is new
issuance. There is no such thing as "reissue", even if two certificates are
markedly similar in various aspects.
The Baseline Requirements allow you to validate at T=0, issue at T=38 for
L=39, where T means 'time' (and 38 just means 'one second before 39
months') and L means lifetime.
However, if a new certificate is issued - with new serial and public key,
at T=40, the Baseline Requirements require this information be revalidated.
But is this stated explicitly, or simply an interpretation?
That's a bit harsh on the subscriber (for a simple failure to notify),
but probably within the legal requirements of the BRs.
Why is it harsh? CAs are required to revoke such certificates. The fact
that the Subscriber Agreement was simply one way of describing the
Revocation Requirements. GlobalSign is equally obligated to revoke under
4.9.1.1, Item 6, which states
"6. The CA is made aware of any circumstance indicating that use of a
Fully-Qualified Domain Name or IP
address in the Certificate is no longer legally permitted (e.g. a court or
arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or services
agreement between the Domain
Name Registrant and the Applicant has terminated, or the Domain Name
Registrant has failed to renew the
Domain Name); "
As this seems to be a multi-SAN certificate for some kind of hosting
provider (based on the descriptions of the how the "product" works),
quickly and suddenly revoking the certificate for all the currently
hosted domains because the hosting provider was late in reporting that
some other domain names should be removed from the shared certificate
would be disruptive to those other domains.
Noting that the potential for abuse would be limited to this supposedly
legitimate hosting provider participating in an attack that would
redirect a formerly hosted domain name to a server with access to the
hosting providers private key and a willingness to provide content for
that domain name (rather than a "no longer hosted here" or
"unconfigured domain" error page).
Hence my suggestion that a more cooperative (but slower) procedure for
replacing the certificate with one that contains only currently
permitted domains might be acceptable.
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
