- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 18 Apr 2011 10:25:29 -0400
- To: public-xg-webid@w3.org
On 4/18/11 9:56 AM, Henry Story wrote:
> On 18 Apr 2011, at 15:28, Kingsley Idehen wrote:
>
>> On 4/18/11 5:27 AM, Henry Story wrote:
>>> 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
>> If the following are true:
>>
>> 1. WebID is scoped to HTTP scheme URIs
> Why? whatever the URI scheme, without a SAN or an IAN field, there is no place to put that in the cert.
>
>> 2. Empty SANs not acceptable.
> Not sure I understand.
>
>> Again, not a problem per se., but lets be clear about these matters.
>>
>>> + many servers (Apache) only accept X509v3 properly configured certificates. This has to be taken into account in a programatic rollout process
>> For sake of Apache? If you are going to justify things for sake of Apache based on installed base, then you have to be consistent about the effects of ubiquity in other realms e.g. items 1&2 re. factors that drive adoption and rollout.
> This was to reply to Peter Williams' suggestion that "I believe webid should be *required* to work with v1 certs, and v3 certs with zero extensions."
>
> 1. I don't see how they can work with v1 sites certs anyway
> 2. Why make such a statement if it is going to reduce the deployability of WebID?
>
> Much better is to work out what the most likely way of writing X509 certs so that they can be accepted as widely as possible. Clearly the adopting server should be able to implement webid authentication. In any case it may be that this should go in an auxiliary document on cert creation and server setup to help people do what works best.
Re. all of the above:
Certificate (I just cut and pasted this from Wikipedia bar tweak to
validity date range) without anything in the SAN:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 2012 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft,
CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
Note: there is a mailto: scheme URI attribute=value pair associated with
'Subject':
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft,
CN=www.freesoft.org/emailAddress=baccala@freesoft.org
If that's all there is in a Certificate, bearing in mind this is the
very cheapest Certificate to produce in the real world. Ditto most
prevalent i.e., no SAN, why shouldn't WebID be capable of doing this? It
just boils down to being scheme agnostic and letting the IdP deal with
the de-reference functionality. Remember, Linked Data is just a Webby
way of handling de-reference and address-of operators that lies at the
root of all forms of data access by reference.
Webfinger and Fingerpoint deliver mechanisms to WebID protocol compliant
IdP platform developers for dealing with this kind of certificate. All
WebID has to focus on is being:
1. scheme agnostic
2. clear about heuristics for establishing canonical WebID in a Cert .
Kingsley
>> We have to be overtly consistent :-)
>>
>> [SNIP]
>>
>>> Henry
>>>
>> Kingsley
>>
>>> 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/
>>>
>>>
>>>
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> President& CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
>>
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Monday, 18 April 2011 14:26:28 UTC