Pedro, Thanks for the quick and detailed replies! A few responses inline.
On Thu, May 24, 2018 at 8:19 AM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > * 1.5.4 requires a full meeting of the CAA to convene for updates, which > > may make it difficult to have the CPS (and the attendant CA policies) > > reflect the BRs > **** > I understand you mean the PAA. As we say in the CPS “Minor versions only > require the participation of a single member of the PAA in order to approve > the publication of a new version.” This accelerates the process for quick > amendments like the ones derived of your kind review (I’m myself member if > the PAA). > **** > Thanks. I did mean PAA (had CAA on the brain), and mostly wanted to make sure that we don't have the same process overhead that other CAs have reported with updating CP/CPSes for compliance. The structure of the OWGTM suggested an independent policy authority that then set policy for WISeKey to implement, which sounded like it could lead to these problems. > > * 3.2.6 notes an accreditation process for interoperating, but doesn't > note > > whether that includes audits consistent with section 8 of the BRs > **** > We set the requirements for audit and compliance and audit in section 8 of > the CPS, and that has to be respected in any case. This particular section > is just pointing some additional controls related to interoperation, but > frankly speaking I don’t see of much relevance, I could easily change it to > “No stipulation”. > **** > Thanks for clarifying. Understandably, there's usually several places and ways that one can express information in the CPS, and that's part of why we do these detailed reviews - to make sure that things are both internally consistent and contain the relevant information. I'm supportive of including more details about the operational aspects, and so I think it's good that you included this. My main concern was "They list these additional controls, but how do they validate they are followed" - so perhaps it's as simple as just mentioning Section 8? To be clear, this is minor (meh) - I think your explanation suffices, and you could change to "No stipulation", make no changes, or make changes to reference other sections, and I think they'd all be good. > > * 4.3 states "The OWGTM is not responsible for monitoring, research or > > confirmation of the correctness of the information contained in a > > certificate during the intermediate period between its issuance and > > renewal, ", which in one read, is entirely consistent with 9.6.1 of the > BRs > > (consistent in that it's at time of issuance), but in another read, could > > be seen as conflicting with 4.9.1.1 of the BRs > **** > Maybe is a problem of language or interpretation, but we say that once the > certificate is properly validated and issued, we can’t control the ulterior > correctness of the information (i.e. change in domain ownership) until a > new validation round (I.e. for a renewal) is performed. I would appreciate > more details in your concern and I’m afraid I couldn’t find the > relationship with BR-4.9.11 which is related to revocation status. > **** > Yeah, I think it's just a language/interpretation issue. This wasn't a big concern (hence meh). Section 9.6.1 of the BRs makes it clear that the issuance of a certificate is a certification at a point in time - that CAs can't continually monitor the information for change (as you mention). That said, the BRs also obligate Subscribers to notify CAs of changes (9.6.2) and for CAs to act upon such notifications (4.9.1.1, revoking for material changes), so I was calling out that one possible interpretation is a suggestion that OWGTM *won't* revoke if they become aware that the information changes (4.9.1.1). I don't think that was the intent, but it was ambiguous enough that I wanted to call it out and make sure we're on the same page :) > > * Section 5.2.2 / 5.2.4 don't detail the minimum number of people > required > > for certain activities. > **** > The fact of mandating separation of duties would imply a minimum of two > persons, but I never saw these details on the number of people per task in > other CPS… Is this really needed? > **** > You'd be surprised - there are some who argue separation of duties can be met by the same person, acting in different roles. I've sadly had this come up in other compliance exercises (FIPS), in which duties are split between 'logical' roles and 'physical' roles - in which the same physical person can (not simultaneously) operate many logical roles. I agree that it's not something consistently applied through CPSes - the sheer number of them make it hard to make sure we give consistent and reliable feedback on each and every one for the same issues, and especially as patterns change over time, different issues come to the forefront. It was from recently dealing with compliance issues (unrelated to CAs) that the physical/logical distinction came up, and so it was brought ot mind when reviewing. I'm always a fan of stating the obvious ;) > > * Section 6.2.4 states that CA backup keys are "typically" store > encrypted. > > What protections are in place if they're not encrypted? > **** > Sorry, I just realized about this language problem… this has been edited > to “always” in the new CPS update. We say in the same section that these > backups are kept in hardware cryptographic modules, so obviously it can’t > be in unencrypted form. > **** > Great! Reassuring. > > * Section 7.3.2 misunderstands OCSP extensions as being about the > > certificates, rather than extensions within OCSP responses (such as CT > > extensions, should that be supported, or nonces, if that should > > unfortunately be supported [and it shouldn't]) > **** > Yes, we misunderstood this. I saw in the past that other CPS put here “No > stipulation” so maybe I’ll do the same after studying this more carefully. > **** > Yeah, I think most OCSP responders aren't using extensions widely. nonce is one (and a bad one to support), and the only other one that tends to come up in the WebPKI is CT (which is optional for CAs to support in OCSP responses). No stipulation would work, if you don't make use of extensions. > > * Annex E, 14.1.4 / 14.2.4, notes the use of "Any Other Method" for IP > > validation > **** > Actually we never use any other method, so I removed it of the edited CPS. > **** > Fantastic! > > == Questions == > > * I've confirmed that AUREN is a licensed WebTrust practitioner, as per > > [1]. When reviewing the audit report, I note that a WebTrust seal was not > > provided (which is not a requirement), but that may have masked other > > review items. In examining the report, [2], I noticed some deviations > from > > the IASE 3000 illustrative reporting provided by WebTrust [3] for such > > reports, particularly IN1.1 (which is for WebTrust for CAs) in [3]. > **** > COMMENT FROM AUREN: > These reports were generated around the time of publication and adoption > period of the new templates, being this is the reason of some possible > deviations. Auren is already adopting the new models for newer reports. > > COMMENT FROM WISEKEY: > We get the Webtrust seals for annual audits, but not for point-in-time or > first 3-month period audits. > **** > Thanks. That's a reasonable explanation - I know the illustrative reports spent a lot of time coming, and came at different paces. > > * In the illustrative reports, it calls out being engaged in a > reasonable > > assurance audit, while in the AUREN report, it states it has audited > > management's assertion. Is there significance in the deviation of > language? > **** > COMMENT FROM AUREN: > There are two types of reports, the “attestation engagement” and the > “direct engagement”, as indicated in IN1.1 e IN 1.3 ( > http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf). > Traditionally we always did the first one and it’s also the one that the > rest of practitioners commonly adopt. > **** > Understood. And understanding the type of engagement was part of why I raised it - wanted to make sure I properly understood the type of audit. > > > * [2] does not list the location of the CA services, although [4], > oddly > > enough, does. This is worth following up on. > **** > COMMENT FROM AUREN: > This is related to the models used for each report, as the ones used > previously for Webtrust 1.0 weren’t including this information. > > COMMENT FROM WISEKEY: > Evidently, all operations for all Roots are done from the same site in > Geneva, Switzerland. You’re invited to a Swiss cheese Fondue in the case > you want to check out! > **** > The big concern here is making sure that it's plainly stated in the management assertion and report. For example, we don't want a CA with a copy of the key material in their evil secret bunker, and which spins out MITM certs, to be considered out of scope for the audit :) For example, some CAs present separate audit reports for different physical locations, and when we see something like that, it's a lot more work - hence why it's desirable to make sure locations are listed, so we know what the auditor (and management) are attesting to. > > > * It notes that external RAs are used, but does not note that key > escrow > > or certificate suspension are out of scope - meaning they are in scope. > > This is consistent with the CPS [5] in Section 4.9, which notes that > > non-SSL certificates may undergo suspension, and Section 4.12, which > notes > > non-SSL end-entity certificates may undergo escrow. > **** > COMMENT FROM AUREN: > This is also related to the model used for the reports, as this was not in > previous versions. It’s confirmed that escrow was out of scope. > > COMMENT FROM WISEKEY: > Regarding escrow... We left that open in the CPS, as it happened in the > past that some technically constrained CAs that customers implemented with > Microsoft Certificate Services implemented the native key escrow capability > for encryption certificates and we allowed this for these customer-owned > constrained CAs, but we, as WISeKey, we don’t provide escrow services to > our certificate subscribers. > **** > Thanks for clarifying. Indeed, the CP/CPS made it clear that this was not applicable to the SSL case, which is exactly what we want to see. Sorry, this was more a statement of my examination than a question - it's a thing that would normally raise eyebrows (escrow and suspension), included in the scope of an audit - but the CP/CPS detailed that it does not apply to the SSL/TLS case. > > * In listing auditor responsibilities, it explicitly notes that it did > > not test the operating effectiveness of these controls (Item 3 in the > > illustrative report, which is explicitly called out as out of scope in > [2]) > **** > COMMENTS FROM AUREN: > This is an erratum coming from reusing the PiT report. Obviously all the > tests on the controls were done, as we are providing our opinion on the > period. > **** > Our default is to assume all omissions are material and intentional (... as they have been by some CAs in the past), which is why I flagged. Is it possible to reissue the report to ensure this is clearly stated as such, since it sounds like AUREN did include these activities in scope of their engagement. > > > * As noted, the key generation was performed in May, and this audit is a > > period of time audit beginning in September. This does mean that there > is a > > gap in the audit coverage - from May through September - that's difficult > > to reason about. Are there any other supporting documents that would help > > assuage these concerns? > **** > COMMENTS FROM WISEKEY: > We had a pause period between the Root CA Ceremony and the creation of a > first issuing CA, so actually there weren't operations to audit. > That’s the reason of the “gap”, as the Root didn’t issue any certificate > and was just left deactivated, so the first period audit started with the > effective start of operations and verified a first three-month period after > this start of operations, during which we only issued a few test > certificates. > **** > So, one area that we've discussed with WebTrust about this is the Root Key Generation Ceremony Report (IN5.1 from the Illustrative reports), along with reporting on the CP/CPS that governs that key and its physical protections, and then on to actual operations. The goal here is roughly: How, as a community, do we make sure that when it was left deactivated, it wasn't just left under someone's desk with no key protections, and which might have signed things that come back to bite us later? We've seen CAs in the past fail to maintain physical access logs, for example, and thus there's no way anyone can be really sure what happened to or with that key material. There is the challenge that you mention - which is how do you opine on operations when it's just sitting unused - but there are still controls in place (such as physical security, auditing, access controls) that presumably are being practiced. I'm a bit uncertain on how best to proceed here on this. I'd like to seek feedback and understanding from our WebTrust & CPA Canada colleagues about how, procedurally, this is handled - as this has been a topic of discussion for several years, and we've heard several statements about what the expectations are for situations like this. > > * WISeKey CertifyID Advanced GC CA 1 is not disclosed in the CP/CPS > **** > As explained in Bugzilla, we don’t list the Issuing CAs in the CPS, but we > reference https://www.wisekey.com/repository, were the updated list is > maintained. Nevertheless, issuing CAs are always included in the audit > reports. > **** > Thanks, I had not reviewed the Bugzilla entry. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
