Kyle Hamilton wrote, On 2009-03-18 04:20:
> On Wed, Mar 18, 2009 at 3:28 AM, Nelson B Bolyard <nel...@bolyard.me> wrote:
>> b) they have NO CA CERTIFICATES marked as trusted to issue client certs,
>> so they violate the SSL and TLS 1.0 protocols by sending out empty lists
>> of issuer names for CA certs, which give clients no information with which
>> to determine which (if any) of that client's certs should be sent, which
>> defeats automatic client cert selection, and
>
> SSL2, SSL3, and TLS1.0 protocols specifically state that the empty
> list is to be considered the set of all possible certificates. Your
> statement that they are in violation is incorrect.
No, That is incorrect.
SSL2 had NO list of issuer names in its certificate request. The client
had to somehow "just know" which CAs were acceptable to the server.
This was considered one of the larger deficiencies of SSL2 that was
addressed in SSL 3.0.
SSL 3.0 and SSL 3.1 (TLS 1.0) specifically require at least one issuer
name be present in the message. It is a violation of those protocol
specifications to send an empty list of issuer names. Look at the
minimum size of the certificate_authorities element of the message
to see that it is non-zero.
TLS 1.1 (SSL 3.2) in RFC 4346 was the first version of SSL 3.x to allow
an empty list of issuer names. It changed the minimum size of the
certificate_authorities element to zero. It was the first version to
specify what an empty list meant. However, it does not mean "all possible
certificates". The RFC says:
If the certificate_authorities
list is empty then the client MAY send any certificate *of the*
*appropriate ClientCertificateType*, unless there is some
external arrangement to the contrary.
If you doubt this, read the documents for yourself.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
