<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 7:17 AM, <a href="mailto:philliph@comodo.com">philliph@comodo.com</a> <span dir="ltr"><<a href="mailto:philliph@comodo.com" target="_blank">philliph@comodo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="gmail-h5"><div><span style="color:rgb(34,34,34)">* The lack of HSM support is not a concern as HSM manufacturers respond to the decisions of bodies like CABForum.</span></div></div></div></div></blockquote><div><br></div><div>Hi Phillip,</div><div><br></div><div>I've snipped much of your email, since I believe it's neither appropriate nor relevant for the list.</div><div><br></div><div>As you appear to have missed the point I was raising, which is unfortunate given your knowledge of the Web PKI, I would simply again highlight that if such a signature cannot be produced without exposing the key material, then that is very much a concern for the CA/Browser Forum. We have already had this discussion before, but I do not believe you chose to participate, so it is unfortunate that you don't recognize the value in making productive, collaborative progress.</div><div><br></div><div>This is the broader discussion, had during the last F2F (and some time before) about what the intrinsic goals are with the CA/B Forum requiring the use of a FIPS 140-2/3 Level 3 or CC EAL Level 4 key protection device. If the intent is solely for key protection, then the points Peter raised about utilizing 'raw' signing mode (whether PKCS#1 or literally raw RSA signing) are relevant - it suggests that the key material can be protected sufficiently (for RSA key sizes less than 4096 bits, assuming a FIPS-approved mode of operation) while still producing these signatures. If we take the view that such HSMs must operate in a FIPS-validated mode of operation, then it's very relevant to understand what methods exist to produce such signatures while still maintaining that operation (the method Peter raised is generally not available in a FIPS-approved mode of operation, depending on vendor, due to the fact that to maintain the FIPS mode of operation, the HSM needs to produce the message digest itself using an approved algorithm in an validated mode of operation). I realize that, given your general lack of participation in the Forum, except for pointing out when it's doing something you disagree with, you may not have followed those discussions, and may not have been aware that it's still very much an open and unresolved issue, with relevance to the operation of CAs today (particularly those with >= 4096-bit keys) and tomorrow (for those that would like to adopt EdDSA or SHA-3).</div><div><br></div><div>I do hope that, with some time to carefully reflect on the messages on the thread, to recognize where confusion might exist and reconsider the appropriateness of assuming you correctly understand the issue versus asking questions to clarify, you might be able to make a productive contribution to the discussion.</div></div></div></div>