Hi Nick, That's a good idea if we were going to continue with supporting customers like this; however, we're in the final stages of terminating all customers running on-premise SSL CAs. Given the timing, setting up private CT logs wouldn't help because that would undoubtedly take longer than our termination date in about 4 months.
Doug -----Original Message----- From: Nick Lamb <n...@tlrmx.org> Sent: Tuesday, April 30, 2019 3:51 AM To: dev-security-policy@lists.mozilla.org Cc: Doug Beattie <doug.beat...@globalsign.com> Subject: Re: AT&T SSL certificates without the AIA extension On Mon, 29 Apr 2019 12:41:07 +0000 Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > It should be noted that these certificates are not posted to CT logs > nor are they accessed via browsers as they are used within closed > networks, but we'll get more details on their exact usage shortly. Hi Doug, Thanks for reporting this problem, I appreciate that this subCA doesn't see a proportionate reward to logging these certs in the existing well known public logs and so it makes sense that they wouldn't write to them. I'm also glad to hear that a 100% sample policy was in place with, it sounds like, a monthly audit period, given the volumes involved (from what I can see publicly in e.g. Censys) that seems like a good idea. Still, in terms of your audit oversight role it could make sense, as software is replaced/ upgraded, to switch to private CT logging as a substitute for a human role of uploading certs for audit. >From your description it sounds as though GlobalSign reasonably trusts that the assigned AT&T Employee will provide them with an accurate set of certs, the thing we're protecting against here is accident or mistake, not a malevolent subCA operator which would be very hard to detect this way. Unfortunately this employee (and perhaps one or more deputies) were on leave. If that assessment is correct then software which uses RFC6962 methods to write certs on issuance to a log operated by GlobalSign would satisfy this requirement automatically without a human action. With the log not publicly trusted it could operate a much relaxed policy (e.g. MMD 7 days or even not defined, not publicly accessible) but it would avoid this dependency on a specific person at AT&T doing a manual step periodically in order for GlobalSign to have sight of issued certificates. With the relative popularity of RFC6962 logging, this becomes an off-the-shelf hook that can be used to support audit roles easily without either manual steps to export the certificates or special modifications to the issuance software. You mentioned EJBCA specifically in this post, and so I verified that as expected EJBCA does provide a means for CA operators to configure a log without also then embedding SCTs in certificates (which might not be desirable for AT&T's application) Nick.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
