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 09:27:41 UTC