[foaf-protocols] FOAF+SSL and root certificates

[Stephen Dawkins]

On 17/02/2010 01:52, Peter Williams wrote:
> There is nothing wrong with what you just specified.  It's just not part of
> the TLS architecture, that's all. TLS architecture assumes an interplay
> between a (protected) communication stack and a general purpose computing
> process that can interact with that communication stack (through the
> intermediation of a security kernel). If you read the patent, that means a
> socket's layer provider ...and a socket user - in the preferred embodiment.
>
> Sure one could corrupt the cert type field ... so it becomes a general
> purpose vehicle for Indicating a cert type X to a cert selector (assumed to
> be present on the client) - where X is defined (in "some spec") as: those
> cert formats derived from X.509 format that also have a particular extension
> Y. But, this could also be signaled using the signed server cert (rather
> more flexibly).
>
I would disagree with the last statement. As far as I know, there is 
currently no link between the cert the server sends and which client 
cert to select. Where as the CertificateRequest message has a direct 
relationship with what cert to select.

I don't see how adding even more information to this request can not be 
part of the TLS architecture since it's something it's already doing.

> Now, let's ask: if the TLS layer entity within the socket on the server
> receives a client cert that is NOT in compliance, what shall it do? Should
> it check that the cert is not expired (by pinging a VeriSign status service
> giving away knowledge of just who is talking to who?).
>
> SSL/TLS architecture says: these very questions are inappropriate. What the
> SSL/TLS layer entity SHALL do is give the cert to the https layer entity
> (sitting in tomcat user space), and it SHALL decide -- since it has policy
> rules and state (that the TLS engine just does NOT have). Tomcat policy
> designers (like Bruno) can weigh the issues, and get out their programming
> tools to build an https system (or an foaf+ssl system).
>
> You don't need IETF TLS WG to do that. You just start programming - by
> DESIGN. All the major server stack already facilitate this. IN the
> claims-driven security world of websso, its EXPECTED you will build your own
> cert validation logic (since no one assumes "legacy" https conceptions from
> the browser era shall prevail).
>
> So, the SSL/TLS layer entity is NOT involved in determining cert validity
> (or enforcing policy) - and consequently its state tables do not store info
> that SSL3/TLS itself doesn't require. Any state management for "security" or
> "policy enforcement" is the job of tomcat's logic, designed by a security
> (vs crypto) engineer. The SSL3/TLS crypto engine has minimal state,

Right, but this isn't the problem we're having. It's up to the web 
server to validate the certificate. The issue we're having is getting 
the right certificate to us, without limiting ourselves to just using 
the issuerDN for identification.

Regards
Stephen

> carefully controlled so HSMs doing SSL procedures can be rigorously
> evaluated. (A basic rule in security engineering says: never have even 1 bit
> of unnecessary crypto state, since it just opens the door for a
> cryptanalysis method yet undiscovered. Always use layering, so risks are
> isolated by layer.)
>
> Recognize that I'm distinguishing between the TLS layer entity in the HSM
> (or windows kernel) doing crypto (the domain of IETF TLS WG), from the cert
> logic (typically) executed in user space by such as tomcat (specifically out
> of IETF scope). The cert logic is programmed in some listener (e.g. tomcat)
> that is specifically NOT doing crypto within an evaluated crypto boundary -
> but it Is performing a cert-related security enforcing function defined by
> the https or pop3s spec or some profile thereof (e.g. foaf+ssl)
>
>
> (*) Ive argued for a while that FOAF+SSL will eventually stop using SSL as a
> blackbox, but will need to "profile" SSL for its custom security needs. I
> think we have arrived at that moment. One needs a fundamental rethink of
> https, for semweb.
>
>
> -----Original Message-----
> From: Stephen Dawkins [mailto:elfarto at elfarto.com]
> Sent: Tuesday, February 16, 2010 2:08 PM
> To: Peter Williams
> Cc: foaf-protocols at lists.foaf-project.org
> Subject: Re: [foaf-protocols] FOAF+SSL and root certificates
>
> On 16/02/2010 20:20, Peter Williams wrote:
>>
>>>> Long term. Enhance TLS to expand it's ability to select client certs.
>>
>>> Agree!
>>
>> I don't.
>>
>>
>> TLS specifically separates trust management (client certs) from what IETF
>> TLS WG is scoped to standardize.
>>
>> That is, you'd have to change 15 years worth of design policy on
> SSL3.1/TLS.
>> Basically, policy says that the socket provider will cooperate with the
> app
>> - which does cert selection/management according to the needs of ldaps,
>> pop3s, ftps3 or https (any 100 other SSL3 apps without published url
>> schemes). However, TLS standard itself says NOTHING about what the app
> does
>> or should do, re certs (or kebersos, or whatever non-cert stuff the
>> negotiated ciphersuite calls for).
>>
>> TLS just standardized what folks used to call the service access point
>> between the app and the socket provider (a few messages).
>>
>> (https has needs for certs quite different to what ftps needs The
>> conversations are quite different, and express different requirements on
> the
>> secure channels. FTP has resume modes quite different to http. One must be
>> careful on using stream ciphers, including web vs internet-centric
> protocols
>> with resume and reliability capabilities - ws-atomic, etc)
>
> I don't understand. TLS provides the ability for the server to request
> that the client send it an X.509 certificate. What is the issue with
> adding the ability for the server to request that it wants certificates
> with some specific extension(s)?
>
> Regards
> Stephen
>
>