Re: Rationales for CA clearance constraints

[Yoav Nir <[e-mail]>]

On Oct 27, 2008, at 2:13 AM, BRUMBY, Ian wrote:

> My comments on the topic:
>
> The Clearance attribute is defined in the current X.501 (2001 and v6  
> draft) with an OID of 2.5.4.55. RFC 3281 (as referenced by draft- 
> turner-caclearanceconstraints-01.txt) defines it as 2.5.1.5.55. It  
> refers to X.501-1993 as the source of this definition. I’ve dug up  
> the 1993 standard and can’t find any reference to Clearance. If  
> Clearance Constraints are implemented, maybe it should be clarified  
> if it constrains X.501 (2003) Clearance attributes, if they are  
> present in the certificate, or specifically doesn’t constrain them.
>
> With regards as to whether Clearance should be held in the  
> Certificate or the Directory:
> I’ve heard concern that it shouldn’t be held in either. In a  
> Prisoner of War scenario it potentially identifies the people with  
> the potential to have the most knowledge.
> FYI – at least one Directory vendor is using the Clearance attribute  
> on the Certificate that is used to bind to the Directory to control  
> access to the Directory.
>
> Ian Brumby
> BAE Systems

On recent discussion on the TLS mailing list, someone said that  
browsers will silently send a certificate if prompted to by HTTPS web  
servers. So your comment 2a has broader application.

It's not just Iraqi insurgents capturing a US or British soldier and  
checking his or her certificate (terrorists as relying parties), but  
if a DoD employee uses their work computer to surf to, say, Amazon or  
gmail, their name, rank and clearance levels leak to that party.

I have no idea what's the harm in telling Amazon, gmail or the Russian  
Mafia that you have top secret clearance, but it sounds bad.