Comments inline. > -----Original Message----- > From: Volker Simon [mailto:volker.si...@db.com] > Sent: Friday, December 06, 2013 10:09 AM > To: wpkops@ietf.org > Cc: Rick Andrews > Subject: RE: Early draft of vendor questionnaire [I] > > 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.
I understand now. I would suggest that we don't extend the survey to ask about client certificate-based authentication, because some folks think it's already too long and complex. If you or others disagree, please let me know and I'll follow consensus. > “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. I see. Can you suggest what question to include in the survey? > “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? OK, I'll add a question about SCEP support. > “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. Can you suggest what question to include in the survey? > 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
