On 05/05/2017 17:37, Gervase Markham wrote:
On 04/05/17 19:30, Jakob Bohm wrote:
1. Issue D actually seems to conflate three *completely different*

Are you sure you are not referring to the Issues List document here
rather than the proposal?

I am referring to the "summary" of D in the proposal, which talks about "Test Certificate Misissuance - issuance of several thousand test certs...", the descriptions I have found in the newsgroup talk about the separate situations I call D1, D2 and D3, each of which was different in their degree of misissuance and in their quantity.

I think summarizing it as misissuance times several thousands leads to an exaggeration, and a suggestion that problems in one part occurred also in another part.

From my understanding of past discussions:

D1 had actual misissuance, violation of procedures and apparently no
separation of duties.  But it was a small number of certs, the private
keys never left Symantec, the certs were quickly revoked, it was years
ago and other concrete measures were taken.

D2 only violated a form requirement (that an actual company name should
be in the O field), but it was a deliberate violation of procedure, a
lack of RA oversight, collusion between separated duties at the RA and
a large number of certificates.  And it was relatively recent.

D3 had actual misissuance (where CrossCert didn't control the test
domains) a deliberate violation of procedure, a lack of RA oversight,
collusion between separated duties at the RA and it was relatively
recent.  But it was apparently a smallish number of certificates (I
don't think there was an actual counting of how many certs were
actually in category D3 versus false positives from issue D2
and valid uses of the word test).

Please correct me if I missed some other test certificate misissuance incidents.

2. If the remaining unconstrained SubCAs are operated by Symantec and
  subject to (retroactive if necessary) compliance audits showing that
  they don't issue certs that could not (under the BR and Mozilla
  policies) be issued from a public Symantec CA by an "Enterprise RA"
  (as defined in the BRs), could those SubCAs not simply be
  reclassified as "public SubCAs" for Mozilla/BR policy purposes while
  remaining further usage limited by actual Symantec practices and
  contractual arrangements beyond the BR/Mozilla policies?

I'm afraid I just don't understand this.

Symantec has claimed that some of the remaining unconstrained SubCA's
identified before my post (they had not yet commented on the most
recent batch found) are hosted within Symantec's infrastructure, which
means that Symantec probably has some direct control over issuance
limitations, as well as complete logs of all issued certs.  This could
mean that reinterpreting their status as "public SubCAs subject to
Symantec policies and audits" rather than "flawed TCSCs lacking proper
'technical' constraints" could make them compliant.

Since such a formal/legal reinterpretation of the ground facts would be
retroactive going back from some time in May 2017 to when each SubCA
was issued, the related rephrased policy documents and additional BR
etc. audits would have to be similarly retroactive.

The goal of such a paperwork exercise would be to avoid revocation and
replacement of the EE certs issued from the SubCAs thus rescued.

   - Is it really necessary to outsource this to bring the Symantec PKI
    under control?  Or was this simply copy/pasted from the
    WoSign/StartCom situation?

Nothing like this was proposed for WoSign/StartCom.

I seem to recall that making WoSign/StartCom a (possibly disguised)
reseller of certs from another CA was a suggestion made as to what
WoSign/StartCom could do to keep their customer relationships during
their minimum 1 year of complete distrust.

   - If this is outsourced as suggested, how can/should Symantec
    continue to serve customers wanting certificates that chain to
    older CA certs in the old hierarchy.

The old cross-signs the new.

Some of the examples I mention seem to have tree height or other technical limitations baring this. Which means that to serve those
segments, Symantec would need to operate the core of their CA
infrastructure while not having the large volume of WebPKI and S/MIME
certificates to fund basic operations.

Also some of these operate in peculiar (CP specified) modes that
most/all other CAs don't have ready systems to handle.  One variant
involve submitting the item to be signed to Symantec for (automated
and/or manual) inspection of the item, issuance of a one-off
certificate for signing that item followed by the immediate destruction
of the private key (this allows individual signatures to be revoked by
revoking the associated one-off cert).

   - Could some of the good SubCAs under the "Universal" and "Georoot"
    program be salvaged by signing them from new roots and adding the
    cross certs to default Mozilla and Chrome installations (so servers
    don't need to install them)?  For example, if the legit EV SubCAs
    under "Universal" are cross-signed by a (new) "EV-only" root, could
    Mozilla move the EV trust to that new root, thus removing the
    risk of EV-trusting any other "Universal" subCAs.

I'm sure we'd be open to discussing implementation details like that.


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

Reply via email to