RE: self-signed

If someone send me a v1 cert with a recognized naming element with URI, I
will be processing it.  

As you say, others may take v1 and v3 certs and.pr v3 certs only. Outside
webid conformance, they may impose interoperability rules suiting their
intranets/extranets, whereupon they may reject a v1 cert format or any v3
cert format with extensions that do not meet their minimum requirements.

What matters to me is the conformance rule, not the distinct processing
rules by an inifinite byumber of relying parties which may and properly
proper should define their own minimum on the  format itself (v3 only, says
ICANN, say - acting as policy authority for CAs). We have no policy
declaring language for required claims (unlike the world of ws-trust, which
allows claims negotiation).

In my case, I will allow the relying party to reject a v3 cert or v3 cert
with extensions. I will also allow the RP to reject any cert that is not a
trust anchor grade self-signed cert - that is the issuer and subject fields
in the v1 name fields fail to be identical. I do not expect the conformance
suite (or its main test site) to enforce those rules.

Remember, we are defining what is conforming, not what is useful. We are
defining the test - which is a "model" relying party that best indicates the
assume design ideals - understanding that most sites may not share all the
assumptions, and will define some deviation. The goal is to get 80% of folks
interworking despite a myriad of minor deviances, each of which are not TOO
impactful on the goals of the movement.

I'll be scanning each rdn in a v1 cert for conformance to a URI. If it looks
like a URI from its form, I will treat it as one - regardless of its OID -
will be my rule.

-----Original Message-----
From: Henry Story [mailto:henry.story@bblfish.net] 
Sent: Monday, April 18, 2011 2:27 AM
To: peter williams
Cc: 'Mo McRoberts'; public-xg-webid@w3.org
Subject: Re: self-signed

It is true that we need to think more carefully about the relation between
the claims made in the certificate and the authentication. 

 . WebId authentication is orthogonal to certificate based authentication
(This is true for Dane too)
   + it can work with x509 certificates but we could also imagine a future
version of TLS that would only send bare keys 
   + it also means that claims made in X509 certificates can work just as
they do now
     If a CA places a WebID in the cert, then the CA claim functions and the
WebID authn too. If they contradict each other then I would say it is up to
the authenticating party to adjust his trust. If he only goes with the WebID
authn, then he cannot rely on the CA statements. If he relies on the CA only
then he can't trust the WebId process one. The best usually is to refuse.
   + the CA based authentication can itself be WebId anchored
     We could have root CA's with WebIds whom we trust because of their
position in a network.

  . on the X509v1-v3 issue
   + X509v1 does not have SAN field, so it's not much use practically for us
   + many servers (Apache) only accept X509v3 properly configured
certificates. This has to be taken into account in a programatic rollout
process

  . what is a certificate?
    It is a document making a claim signed by a CA. The rules are setup to
delimit when and how far the CA can be responsible for his affirmations. 
    + these rules don't change when the certificate is self signed. 
      - if the Cert gives a time validity limit, those should be respected.
(The use case here are short lived certificates put together for more public
terminals. Remember that those certs are not self signed)
    + when the CA rules are broken then the CA based trust chain can no
longer be used - sometimes this may be acceptable.

So in short a CA based statement is one anchor in the web of trust. The
WebID based one another. Combining them increases trust. Even for self
signed certificates. 

   Henry  


On 15 Apr 2011, at 18:43, peter williams wrote:

> Think about the logic, though. My suggestions are there to force the
issue!
> The rule from ISO is, recall, an obligation on a cert-using system 
> (not a cert-minting system). You can use any cert minting system you 
> like for conformance (including one making older v1 certs.) ISO does 
> not mandate use of v3, or any extensions, critical or otherwise. 
> IETF's PKIX profile of
> X.509 does, however! But, we are NOT PKIX conforming, or claiming to 
> be - so far.
> 
> We don't *use* the extensions in webid conformance (whether critical 
> or not). Why not? Because we don't confirm that the cert is signed or 
> that the cert's signature verifies (if it is signed). The protocol 
> makes NO assumption that the extensions have any integrity; and are 
> thus in the space of the attacker. Back to my point - that formally, 
> its not a cert (since not-certs don't have to have their critical 
> extensions processed by conforming, cert-using systems). Anyone can 
> claim that their cert-like blob chains to VeriSign, to get social 
> engineer brand kudos say, even though it doesn't in fact do so. (Think 
> phishing scams.) As designers, we don't use variables subject to 
> active, unauthorized modification, especially crypto-control values. 
> Thus, the cert-like thing is NOT a cert, and thus we ignore its critical
extensions.
> 
> You might argue... well we cannot use the SSL signature from the 
> browser either, since that depends on the public key value from said
> (integrity-less) cert-like thing, Peter! The argument would be valid 
> until we remember only the true user has the signing key (not the 
> attacker). Only this fact is assumed by our design here, which is NOT a
cert-using system.
> Even the much-discussed SSL MITM agent used in corporate firewalls 
> cannot NORMALLY spoof the user's signing act. (Corporately escrowed 
> employee keys are an well-known potential exception; but let's assume 
> their use to attack the employee's reputation in public is ab-normal, 
> being a breach of civil duty of the employer -  a fraud, if you will).
> 
> And, this is where rubber meets the road. WebID assumes that the 
> supporting TLS server endpoint (windows kernel, servlet container, 
> apache module, ...) verifies the inbound client authn signature from 
> the SSL protocol (probably using the public key from the cert on the 
> wire, though this is depends on platform or config). WebID then 
> specifies EVERYTHING else that shall/must occur, for a _conforming_ authn
act.
> 
> Given the above,  the cert presented by the user is not, in all cases, 
> a certificate in the normal sense. Rather, it's a convenient data 
> format for the public key and the SAN claim so these 2 
> security-enforcing values get signed under the SSL macs and client 
> authn signature, in commodity system (that know the underlying 
> ASN.1/BER/DER format). But, there is *nothing* about the (assumed 
> un-signed) cert that does anything security enforcing. If the RSA key 
> within the cert-like value has a subkectPublicKey recognizable as an 
> RSA public key but has a cert-signature marked 
> unknownSigningAlgorithm.oid (that only 2 people in the world have 
> software for), it doesn't matter (to webid validation) that the signature
is unverifiable, and unverified.
> 
> Now, there is a flaw in the argument above.
> 
> If we assume that the user's signature (courtesy of SSL client authn) 
> over the cert-like blob in the SSL handshake is good for the SAN-URI 
> field (an extension, remember), we COULD assume it's good for the 
> other extension values - such as key usage, extended key usage, cert 
> policy oid, cert policy qualifier, and all the rest.
> 
> But, recognize that said extensions are self-asserted, in the webid 
> conformance model. This logic says: I, user, hereby assert that my 
> cert-like blob (not that it's a cert in the formal sense) is 
> conforming to the BBC cert policy (not that it does), as asserted in 
> the relevant extension. I hereby assert my signing key is good for 
> certSigning key purposes, and the basicContraint=CA field. I can 
> obviously self-assert any old crap, including wrong facts.
> 
> If, furthermore,  I mark these extension "facts" critical, under 
> normal ISO enforcement rules for true-certs an acceptor MUST process 
> these per the semantics of X.509/PKIX standard. This is the case in 
> question, addressed by Joe and apache enforcement logic. He is arguing 
> that a webid-conforming validator SHOULD/MUST reject Hans cert, since 
> it has critical extensions that the endpoint cannot/willnot process. 
> I'm saying it should not reject, to be webid-conforming. I should 
> ignore them. He is saying, its up to the user to figure what not to
do....for any given endpoint.
> 
> What is the difference between the two positions?
> 
> 1) from Joe, if you do you use any critical extensions, dear 
> self-asserting user, you must know WHICH ones work at any one of a 
> billion different resource servers, each one of which has different 
> rules. If you use a third-party issued cert (which may WELL have said 
> extensions), things get no better. This is what killed client cert
adoption, for 15 years (in my view).
> 
> 2) from Peter, webid validation makes no use of extensions (other than
SAN).
> Thus one can always self-assert, based ONLY on control of private key. 
> The cert is a cert-like thing, that is simply a container for a few 
> fields, signed by the SSL handshake. Those fields have no X.509 
> conformance obligations, since webid is not a cert-using system.
> 
> Now, under 2, in the windows code I cited the other day, I allowed the 
> resource server to go beyond conformance, under the webid spec. If the 
> cert-like blob is found to be present in a certain windows cert store, 
> as resource server the code then double-dips - and validates ALSO 
> under PKI chaining rules. This is "normal" PKI chain validation, and 
> only happens for certs-like blobs I've elected to treat as true certs. 
> The cert-like thing, now viewed as a cert, then has to satisfy 
> ADDITIONAL rules, not enacted by the webid code. Its validated using 
> normal cert-using logic (implemented by the windows cert chain or peer 
> chain trust provider - that is reasonably PKIX-conforming).
> 
> At this, point I may reject Hans certs - even though Henrys cert 
> checker says its good. I am a non-conforming system at that point, 
> since I added the value of chain-trust requirement (that is largely 
> driven by the v3 extensions). I may well reject the authn, at that 
> point. But, its because I'm now in non-conforming mode.
> 
> If I look forward a few years, to the usual legal semantics wars, this 
> all matters IF one question whether an act of webid authn is 
> tantamount to legal signing act, under E-SIGN laws or equivalent. 
> E-SIGN covers click-wrap and form-submit grade digital signatures, 
> remember (pressing a web form's submit button can constitutes an 
> e-signature, remember, under such laws). By agreement of the parties, 
> one can treat an act of webid authn as an enforceable (legal) 
> signature, similarly. But is it a valid signature, under legal rules? 
> Says counsel, Henry's conformance checker says it is a valid act of 
> authn, per conforming to the webid protocol spec. Says contrarian 
> counsel, I say it's not (under my client's value-adding regime, that
imposes addidtional obligations on the asserting party).
> 
> Which is true? Did user intend to sign and bind him/herself to the 
> license or not, on release his/her webid client authn cert-like thing? 
> Does the fact that the browser signs ANY handshake after the first 
> (without presenting a
> dialog) matter?
> 
> (In my setup, I mint keys with more rather more care and controls than 
> Henry's and other's cert issuing website. I set the rule that ANY use 
> of the user's signature key requires consent of the user, each 
> application. Windows pops up a dialog box not to re-select the cert to 
> be release, note, but to re-authorize the act of signing the SSL 
> messages.)
> 
> 
> 
> 
> -----Original Message-----
> From: Mo McRoberts [mailto:mo.mcroberts@bbc.co.uk]
> Sent: Friday, April 15, 2011 3:41 AM
> To: peter williams
> Cc: public-xg-webid@w3.org
> Subject: Re: self-signed
> 
> 
> On 15 Apr 2011, at 11:28, peter williams wrote:
> 
>> That's fine. But what are we saying in terms of standards?
>> 
>> Are we saying that
>> (a) one must have v3 certs
>> (b) one must have extensions x y x
>> (c) if one does meet (b), x must not do this or that?
>> 
>> I believe webid should be *required* to work with v1 certs, and v3 
>> certs with zero extensions.
> 
> Why? WebID certs are going to be generated by software designed to 
> generate WebID certs, and v3 cert generation tools and libraries 
> aren't merely prevalent, they're the norm nowadays.
> 
>> Im cannot believe Im about to say this, but, given the nature of 
>> webid protocol, one could go further. A webid validator is required 
>> to ignore all extensions, critical or not. (this is because the 
>> signature on the cert need not validate).
> 
> The X.509 critical extension mechanism is a compatibility system: 
> marking an extension as critical is a way of saying "this extension is 
> important - it alters the meaning of the certificate; if you don't 
> understand it, you shouldn't accept the certificate for any purpose".
> 
> I would be _extremely_ wary of throwing caution to the wind with 
> regards to this and simply throwing it away; rather, documentation 
> concerned with certificate generation should explain what "critical 
> extension" means and what its impact is. Between that and a validator 
> which can say _why_ a certificate is or isn't acceptable, somebody 
> would have to be recklessly negligent (i.e., not test it at all) to 
> produce a "WebID certificate generation tool" (be it standalone, or 
> rolled into something else) which got it wrong.
> 
> Critical extensions may seem like a big head-scratcher now while 
> certificates are being generated by hand, tools are still being 
> developed, good documentation is lacking, and the validator isn't yet 
> ready, but these challenges should be used to highlight the "gotchas" 
> that people are likely to run into, rather than deciding which bits of 
> the rules need to be changed.
> 
> M.
> 
> --
> Mo McRoberts - Data Analyst - Digital Public Space, Zone 1.08, BBC 
> Scotland,
> 40 Pacific Quay, Glasgow G51 1DA, Room 7066, BBC Television Centre, 
> London
> W12 7RJ,
> 0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A
> 
> 
> 
> 
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain 
> personal views which are not the views of the BBC unless specifically
stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in 
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					
> 
> 

Social Web Architect
http://bblfish.net/

Received on Monday, 18 April 2011 15:43:07 UTC