Subject: Re: [wpkops] Early draft of vendor questionnaire

From: Wayne Thayer <[email-masked]>
Date: Sun, 1 Dec 2013 21:40:53 +0000

Rick - please find my comments attached.

Thanks,

Wayne

From: Rick Andrews <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 26, 2013 at 5:27 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

---

From: Wayne Thayer <[email-masked]>
Date: Sun, 1 Dec 2013 21:44:35 +0000

I was struggling with this while I reviewed the doc.  For instance, should
we consider HPKP processing by the client?  Is there a general rule we can
use to identify what¹s in & out of scope?

Thanks,

Wayne

On 11/27/13, 6:20 AM, "Tim Moses" <[email-masked]> wrote:

>Tom.  These are good points.  They relate more to the TLS stack than the
>PKI.  But, they are relevant for all that.
>
>Can you provide specific questions?
>
>All the best. Tim.
>
>> On Nov 27, 2013, at 6:09 AM, "t.petch" <[email-masked]> wrote:
>> 
>> Complicated:-(  Perhaps there is a danger of losing the wood for the
>> trees.
>> 
>> Thus, I think of TLS in terms of cipher suites and think that software
>> vendors would too; the mix and match approach of algorithms in 2) (where
>> is RC4 or AEAD or AES-GCM?) seems likely to produce the wrong answers.
>> 
>> I also think of TLS in terms of versions, of which there are two values
>> that appear separately in setting up a TLS connection, and many software
>> vendors would appear not to understand what the specification says in
>> that regard and so are in breach of it.  Fallback attacks derived
>> therefrom are a significant part of using TLS.
>> 
>> And then there is Key Usage; some check, other do not.
>> 
>> And the hot topic of three years ago was Renego and support for it;
>> still significant today.  Links into fallback attacks.
>> 
>> While a running sore is where does the software get its identifier from;
>> this document keeps talking of DN (I wonder how common that is).
>> RFC6125 should probably be in there somewhere.
>> 
>> And the treatment of user certs (I know what Microsoft does and it is
>> very sensible but suspect that it is unique).
>> 
>> etc etc
>> 
>> Tom Petch
>> 
>> ----- Original Message -----
>> From: "Rick Andrews" <[email-masked]>
>> To: <[email-masked]>
>> Sent: Wednesday, November 27, 2013 12:27 AM
>> 
>> 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.
>> 
>> ------------------------------------------------------------------------
>> --------
>> 
>> 
>>> _______________________________________________
>>> wpkops mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/wpkops
>> 
>> 
>> _______________________________________________
>> wpkops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/wpkops
>_______________________________________________
>wpkops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/wpkops

---

From: Rick Andrews <[email-masked]>
Date: Mon, 2 Dec 2013 15:45:25 -0800

Wayne,

You asked: "Should we also ask about SPDY support?" I'm inclined to think no, because that's sort of an HTTP replacement over and above SSL/TLS. I'm not sure it falls in to the charter.

About RFC6277 (OCSP Algorithm Agility) good point, I'll add that. I created a new section for OCSP Responder (in addition to Server and Client) and also added the question to the Client survey. But what do you mean by "Does there need to be a question about stapling support for multiple signature algorithms?"

Good point: "Should we ask what encoding is supported here (Punycode, UTF-8)" but I think I'll keep the questions to what's relevant for TLS/SSL (what happens if the user types the Punycode but the cert contains only the native name, and not, for example, how names are displayed).

-Rick

From: Wayne Thayer [mailto:[email-masked]]
Sent: Sunday, December 01, 2013 1:41 PM
To: Rick Andrews
Cc: [email-masked]
Subject: Re: [wpkops] Early draft of vendor questionnaire

Thanks,

Wayne

Folks,

-Rick

---

From: Rick Andrews <[email-masked]>
Date: Mon, 2 Dec 2013 15:58:09 -0800

> Hi Rick
> 
> this is getting good now. However I think q6 is too complex
> 
> 6)	Does the product allow for the configuration of multiple
> certificates
> using different public key algorithms (RSA, DSA, ECC) but the same
> Subject DN,
> 
> could be answered yes or no
> 
>  and deliver the most appropriate certificate to each client based on
> the client's capabilities as indicated in the ClientHello message?
> could also be answered  yes or no
> 
> So what if a user has yes for the first half and no for the second
> half,
> or vice versa?
> 
> Maybe best to split into two questions. Same goes for q7.

David, I worded it this way because this is exactly what Apache supports and IE does not. If I broke it up into two questions, and someone answered yes for the first one, and no for the second one, they'd need to explain why they allow multiple certs with the same DN in the first place.

I think that we need to encourage every survey responder to feel free to elaborate on any answer, even if it's a simple yes/no question. Would that help?

> Other minor comments below:
> 
> Q8, Q14, and Q17a) and Q20b) and Q22a) add (tick all that apply)

OK, but do you mind if I say "check" instead of "tick"? ;^) I think that's a Britishism.

> Q9 d. other add Please specify.

Done

> Q17b. What answer are you looking for? If its the numbers 1 to 9 in the
> order of support, then state this (in brackets).

Done

> Q20 c. and d. are a bit vague. What answers are you looking for?

Adam Langley from Google has indicated that not all CRLs are included in Chrome's CRL Set. I was looking for clarity on which ones a CA and/or relying party can expect to be included or not included.

-Rick

---

From: Wayne Thayer <[email-masked]>
Date: Tue, 3 Dec 2013 00:03:07 +0000

> But what do you mean by "Does there need to be a question about stapling support for multiple signature algorithms?"

This may be an ignorant question, but I'm asking if web servers can staple OCSP responses using both SHA-1 and SHA-2 for the same site?

Thanks,

Wayne

From: Rick Andrews [mailto:[email-masked]]
Sent: Monday, December 02, 2013 4:45 PM
To: Wayne Thayer
Cc: [email-masked]
Subject: RE: [wpkops] Early draft of vendor questionnaire

Wayne,

-Rick

---

From: Rick Andrews <[email-masked]>
Date: Mon, 2 Dec 2013 17:00:39 -0800

Ah, I'm not familiar enough with stapling to answer that.

From: Wayne Thayer [mailto:[email-masked]]
Sent: Monday, December 02, 2013 4:03 PM
To: Rick Andrews
Cc: [email-masked]
Subject: RE: [wpkops] Early draft of vendor questionnaire

Thanks,

Wayne

Wayne,

-Rick

---

From: Volker Simon <[email-masked]>
Date: Tue, 3 Dec 2013 09:54:17 +0100

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 [email-masked]<mailto:[email-masked]>

Visit us: https://dbpki.tools.intranet.db.com

From: wpkops [mailto:[email-masked]] On Behalf Of Rick Andrews
Sent: Mittwoch, 27. November 2013 01:27
To: [email-masked]
Subject: [wpkops] Early draft of vendor questionnaire

Folks,

-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.

---

From: David Chadwick <[email-masked]>
Date: Tue, 03 Dec 2013 09:55:41 +0000

Hi Rick

On 02/12/2013 23:58, Rick Andrews wrote:
>> certificates using different public key algorithms (RSA, DSA, ECC)
>> but the same Subject DN,
>> 
>> and deliver the most appropriate certificate to each client based
>> on the client's capabilities as indicated in the ClientHello
>> message? could also be answered  yes or no
>> 
>> half, or vice versa?
> David, I worded it this way because this is exactly what Apache
> supports and IE does not. If I broke it up into two questions, and
> someone answered yes for the first one, and no for the second one,
> they'd need to explain why they allow multiple certs with the same DN
> in the first place.
> 
> I think that we need to encourage every survey responder to feel free
> to elaborate on any answer, even if it's a simple yes/no question.
> Would that help?

Yes, if you have a space at the end of each question where respondents
can add clarifying remarks that would be OK

> OK, but do you mind if I say "check" instead of "tick"? ;^) I think

Gosh, I thought we invented the English language, and corruptions to it
were Americanisms :-)
What do you call pieces of paper on which you transfer money from your
bank account to someone else?

regards

David

>> Q17b. What answer are you looking for? If its the numbers 1 to 9 in
>> the order of support, then state this (in brackets).
> 
> Done
> 
> Adam Langley from Google has indicated that not all CRLs are included
> in Chrome's CRL Set. I was looking for clarity on which ones a CA
> and/or relying party can expect to be included or not included.
> 
> -Rick
>

---

From: Rick Andrews <[email-masked]>
Date: Tue, 3 Dec 2013 11:23:02 -0800

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:[email-masked]] On Behalf Of Volker Simon
Sent: Tuesday, December 03, 2013 12:54 AM
To: [email-masked]
Subject: Re: [wpkops] Early draft of vendor questionnaire

Classification: Public
Hello together,

As a relying party:

Volker Simon

Deutsche Bank AG
Global Technology

Folks,

-Rick

---

---

From: Rick Andrews <[email-masked]>
Date: Tue, 3 Dec 2013 17:06:03 -0800

Tom,

You sent two emails with comments; I'm going to combine them together and address both at once. I'm attaching the latest version of the document.

-Rick

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2013 10:24 AM
> 
> Tim
> Yes, my thoughts have a TLS bias but that is what I got from reading
> the document!

That's fine; I think the WG has a TLS bias.

> And I find the document quite large already and am reluctant to add
> more to it without removing something.

That worries me a bit. The state of Web PKI today is complex. We're trying to find our way through that complexity, and I don't think we'll learn very much if we keep the questions short and/or simple. On the other hand, I don't want this to get too big to be unwieldy.

> I think that Server Q1 is inappropriate for two reasons.
> 1) Different versions of eg Windows Server have very different
> capabilities and I would think it verging on the impossible to fill
> this
> in for the different versions.  Rather, people should be invited to
> fill
> in a separate questionnaire for each version.  And it is the vendor who
> knows what makes sense as a version, thus, as I recall, Windows Vista
> is
> the same as 2008R1, but 2008R2 is the same as 7 ie it is the underlying
> SChannel that matters, not the terms that might be used in marketing.
> 2) Many, if not most organisations, will not disclose market share and
> might stop and go no further - such data is often available but from
> other sources such as Universities and large web sites, not from
> vendors.

I wrote some text in the introduction to encourage responders to make copies of the document for each version, if that's what they'd prefer, or just describe the different behavior of each version in each answer. Let me know if you think that's adequate.

> And a second substantial point is Server Q2 which I find misguided - yes
> you want to know what is supported but I think that this should be in
> terms of TLS ciphersuites - after all, Q8 does not ask what versions of
> SSH are in use!

But this is the Web *PKI* Ops working group, and ciphersuites are not exclusively related to PKI. I'm inclined to avoid discussing ciphersuite support to keep the survey simpler.

> And my third substantial point is Server Q8 which I think fundamental,
> and which should come earlier, perhaps second (assuming that the
> emphasis on TLS is correct); and it is a complex question, it is really
> about the negotiation that takes place to find a version acceptable to
> client and server which in turn affects the available ciphersuites and
> so on.  I am not sure how to rephrase this question and will think some
> more.

I'll move it if you feel it's important. I didn't pay much attention to the order of questions, since I expect that responders will answer all questions.

-------------------------------------------------------------------------

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2013 2:31 AM
> To: Rick Andrews; [email-masked]

See my answer above re: ciphersuites vs. PKI aspects.

> therefrom are a significant part of using TLS.

Can you craft a question to capture this concern?

> And then there is Key Usage; some check, other do not.

I added a question I got from Wayne:
18)	Does the product enforce key usage constraints?
__ Yes, via Key Usage
__ Yes, via Extended Key Usage
__ Yes, via metadata associated with the root

Is that adequate, or do you have additional concerns?

> still significant today.  Links into fallback attacks.

I'm inclined to not include this a) because it's not PKI-related, strictly speaking, and b) to keep the survey simpler.

> RFC6125 should probably be in there somewhere.

Can you craft a question to capture this concern?

> very sensible but suspect that it is unique).

I think in a separate thread, we concluded that user certs were out of scope.

> etc etc

Please elaborate! If you know of additional questions to ask, please feed them to me.

---

From: Tim Moses <[email-masked]>
Date: Fri, 6 Dec 2013 18:04:29 +0000

Rick - The CRL Timeout question had to do with behaviour in the event that no response to the CRL request is received.  How long before the software decides it won't wait any longer and what does it do then?

All the best.  Tim.

-----Original Message-----
From: Rick Andrews [mailto:[email-masked]] 
Sent: Tuesday, December 03, 2013 8:06 PM
To: t.petch
Cc: [email-masked]; Tim Moses
Subject: RE: [wpkops] Early draft of vendor questionnaire

Tom,

-Rick

> Tom.  These are good points.  They relate more to the TLS stack than 
> the PKI.  But, they are relevant for all that.
> 

> this in for the different versions.  Rather, people should be invited 
> to fill in a separate questionnaire for each version.  And it is the 
> vendor who knows what makes sense as a version, thus, as I recall, 
> Windows Vista is the same as 2008R1, but 2008R2 is the same as 7 ie it 
> is the underlying SChannel that matters, not the terms that might be 
> used in marketing.

> And a second substantial point is Server Q2 which I find misguided - 
> yes you want to know what is supported but I think that this should be 
> in terms of TLS ciphersuites - after all, Q8 does not ask what 
> versions of SSH are in use!

> emphasis on TLS is correct); and it is a complex question, it is 
> really about the negotiation that takes place to find a version 
> acceptable to client and server which in turn affects the available 
> ciphersuites and so on.  I am not sure how to rephrase this question 
> and will think some more.

> vendors would too; the mix and match approach of algorithms in 2) 
> (where is RC4 or AEAD or AES-GCM?) seems likely to produce the wrong answers.

> I also think of TLS in terms of versions, of which there are two 
> values that appear separately in setting up a TLS connection, and many 
> software vendors would appear not to understand what the specification 
> says in that regard and so are in breach of it.  Fallback attacks 
> derived therefrom are a significant part of using TLS.

> While a running sore is where does the software get its identifier 
> from; this document keeps talking of DN (I wonder how common that is).

---

From: Volker Simon <[email-masked]>
Date: Fri, 6 Dec 2013 19:09:19 +0100

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 [email-masked]

From: Rick Andrews [mailto:[email-masked]]
Sent: Dienstag, 3. Dezember 2013 20:23
To: Volker Simon; [email-masked]
Subject: RE: Early draft of vendor questionnaire

Volker,

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

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.

Volker Simon

Deutsche Bank AG
Global Technology
Alfred-Herrhausen-Allee 16-24, 65760 Eschborn, Germany Tel. +49(69)910-65335 Mobile +49 1731656228 Email [email-masked]

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

---

---

---

From: Rick Andrews <[email-masked]>
Date: Fri, 6 Dec 2013 10:42:57 -0800

Comments inline.

> From: Volker Simon [mailto:[email-masked]]
> Sent: Friday, December 06, 2013 10:09 AM
> To: [email-masked]
> Cc: Rick Andrews
> Subject: RE: Early draft of vendor questionnaire [I]
> 
> “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?

> ⇒ 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?
 
> 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.
> 
> “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
> 
> 
> - 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).
> → 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.
> 
> Alfred-Herrhausen-Allee 16-24, 65760 Eschborn, Germany Tel. +49(69)910-
> 65335 Mobile +49 1731656228 Email [email-masked]
> 
> 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.
> 
> 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.

---

From: Volker Simon <[email-masked]>
Date: Wed, 11 Dec 2013 19:41:14 +0100

Hi,

"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."

--> I just saw it as an opportunity because unfortunately we see quite often issues within Two-Way SSL implementations. But if this would make the questionnaire too complex I am okay with leaving this one out.

> 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?"
--> As this relates probably more to a certificate rollover support with zero outage we could leave this out too and hopefully get some meaningful answers regarding automatic certificate renewal capabilities (e.g. SCEP, CMP).

If I think this through I guess the authentication/authorization question probably would also just add additional complexity and does not add value if not well understood by the person answering the questionnaire.

Regards,
Volker Simon

-----Original Message-----
From: wpkops [mailto:[email-masked]] On Behalf Of Rick Andrews
Sent: Freitag, 6. Dezember 2013 19:43
To: Volker Simon; [email-masked]
Subject: Re: [wpkops] Early draft of vendor questionnaire [I]

Comments inline.

> administration purposes NOT supporting this. In these cases you have
> to do tweaks by appending a suffix to the subject every second year.

> 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?

> parties. Are you saying that there are some web servers that
> “implement direct trust for authorization”? Can you please elaborate?”
> authorization. In many cases this leads to direct trust
> implementations which causes changes on both sides if a certificate expires.

> You say that you have seen several vendors not supporting the first
> 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.
>
> parties. Are you saying that there are some web servers that
> “implement direct trust for authorization”? Can you please elaborate?
>
> Thanks,
>
> -Rick
>
>
> apart from Rick’s mentioned points in the document I have the
> following
> ones:
> dedicated certificate subject during renewal phases. (one for the
> still valid certificate and one for a queued PKCS#10 for the same subject).
> Mit freundlichen Grüßen / Kind regards, Volker Simon
>
> received this e-mail in error) please notify the sender immediately
> and delete this e-mail. Any unauthorized copying, disclosure or
> received this e-mail in error) please notify the sender immediately
> and delete this e-mail. Any unauthorized copying, disclosure or

---