Classification: For internal use only Rick,
“You say that you have seen several vendors not supporting the first two points. Are you referring to web browsers or servers? Servers generally don’t need to support roots and root stores” ⇒ With the roots and root stores this is okay in these cases where I only have server authentication. But what about webservers where SSL client authentication is supported? There are portals which only allow SSL client authentication instead of username/password. Here at least the server must have configured a list of trusted Client CAs. “Allow parallel existence of at least two unique key pairs for a dedicated certificate subject during renewal phases…” I haven’t heard any cases of this. Do you know of any web servers that don’t support this? ⇒ I know a quite prominent firewall appliance hosting a webserver for administration purposes NOT supporting this. In these cases you have to do tweaks by appending a suffix to the subject every second year. “Support of an automatic renewal mechanism (e.g. SCEP)” ⇒ There are quite a few opensource implementations (e.g. sscep) which can be compiled for any platform and can therefore also be used for managing the certificate lifecycle for webservers. With sscep you could use the old but still valid private key to sign the new CSR (based on a fresh key pair) which is then send to the PKI. I mean the challenge for renewing certificates regularly is valid for any device family, right? “I’m sorry, but I don’t understand your last point about relying parties. Are you saying that there are some web servers that “implement direct trust for authorization”? Can you please elaborate?” ⇒ Yes, unfortunately there are commercial solutions out there not understanding to distinguish clearly between authentication and authorization. In many cases this leads to direct trust implementations which causes changes on both sides if a certificate expires. Regards, Volker Simon ____________________________________________________ Deutsche Bank AG Email volker.si...@db.com From: Rick Andrews [mailto:rick_andr...@symantec.com] Sent: Dienstag, 3. Dezember 2013 20:23 To: Volker Simon; wpkops@ietf.org Subject: RE: Early draft of vendor questionnaire Volker, Thank you for your comments. You say that you have seen several vendors not supporting the first two points. Are you referring to web browsers or servers? Servers generally don’t need to support roots and root stores, but I will add a question about multitier support to the Server survey. If you were referring to non-browser SSL clients, remember that the charter for this group is to document browsers/OSes, and not necessarily non-browser SSL clients like devices. “Support of PKCS#10 creation” – I added a question specifically about support for this standard. Thanks. “Allow parallel existence of at least two unique key pairs for a dedicated certificate subject during renewal phases…” I haven’t heard any cases of this. Do you know of any web servers that don’t support this? “Support of an automatic renewal mechanism (e.g. SCEP)” – I know SCEP is commonly used in devices (and iPhones) but I’ve never heard of web servers using it. Have you? I’m sorry, but I don’t understand your last point about relying parties. Are you saying that there are some web servers that “implement direct trust for authorization”? Can you please elaborate? Thanks, -Rick From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Volker Simon Sent: Tuesday, December 03, 2013 12:54 AM To: wpkops@ietf.org Subject: Re: [wpkops] Early draft of vendor questionnaire Classification: Public Hello together, apart from Rick’s mentioned points in the document I have the following ones: - Support of a multitier CA architecture in general (e.g. root - intermediate - end entity certificate) - Root rollover support i.e. more than one valid Root CA. →I have seen several vendors not supporting these points. - Support of PKCS#10 creation (key generation on hosting machine side). Allow parallel existence of at least two unique key pairs for a dedicated certificate subject during renewal phases. (one for the still valid certificate and one for a queued PKCS#10 for the same subject). - Support of an automatic renewal mechanism (e.g. SCEP) As a relying party: - Clear distinguishment between authentication and authorization. → Many vendors still implement direct trust for authorization which does not give any PKI benefit. This could be done e.g. through the usage of a pattern match of the certificate subject. Mit freundlichen Grüßen / Kind regards, Volker Simon ____________________________________________________ Volker Simon Assistant Vice President | Lead Technical Specialist | CISM Deutsche Bank AG Global Technology Alfred-Herrhausen-Allee 16-24, 65760 Eschborn, Germany Tel. +49(69)910-65335 Mobile +49 1731656228 Email volker.si...@db.com Visit us: https://dbpki.tools.intranet.db.com From: wpkops [mailto:wpkops-boun...@ietf.org] On Behalf Of Rick Andrews Sent: Mittwoch, 27. November 2013 01:27 To: wpkops@ietf.org Subject: [wpkops] Early draft of vendor questionnaire Folks, Here’s a very early draft, started by Tim with updates from David and me. I’ve turned on Track Changes; please feel free to add edits and comments. I’m sure there’s many more questions we can ask. Please pile ‘em on. -Rick --- Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter http://www.deutsche-bank.de/de/content/pflichtangaben.htm. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. Please refer to http://www.db.com/en/content/eu_disclosures.htm for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --- Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter http://www.deutsche-bank.de/de/content/pflichtangaben.htm. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. Please refer to http://www.db.com/en/content/eu_disclosures.htm for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
