RE: self-signed

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.

Received on Friday, 15 April 2011 16:44:01 UTC