![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Martin Rex wrote: > What I meant (and forgot to add) was "certificate-based credential > (self-signed when no PKI is used) as a mandatory to implement > feature for interoperability". > > If support of cert-based credentials is a mere MAY, then I am sure > there will be servers/services where installing or using a PKI > credential is impossible/defective/unusable, and you cannot complain > to the vendor because not-supporting it is fully compliant with the spec. > > Everyone will be happy when Kerberos can be used cross-organization > one day. But until that day, I want to make sure that the customer > has the working alternative to use PKI when there is a need for it. Let me rephrase what you want: * You do not want to require that a server certificate be used when a TLS_GSS cipher is selected * You do want to require that all TLS implementations support for the certificate based ciphers Note that while we can standardize implementation requirements, we cannot standardize the deployment requirements. No one that is promoting TLS GSS wants to eliminate the use of certificate based TLS ciphers. The purpose of adding the TLS GSS ciphers is to provide a solution for environments that certificate management costs exceed the costs of the pre-existing infrastructure. Jeffrey Altman
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS at lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls