- From: Erich Bremer <erich@ebremer.com>
- Date: Fri, 06 Sep 2013 15:55:19 -0400
- To: Andrei Sambra <andrei.sambra@gmail.com>
- CC: Henry Story <henry.story@bblfish.net>, "public-webid@w3.org" <public-webid@w3.org>
- Message-ID: <522A3327.7030304@ebremer.com>
On 09/06/13 3:48 PM, Andrei Sambra wrote:
>
> On Fri, Sep 6, 2013 at 9:41 PM, Erich Bremer <erich@ebremer.com
> <mailto:erich@ebremer.com>> wrote:
>
> On that note, should we add language to support certificate
> revocation lists in the cert ontology?
> See: http://www.ietf.org/rfc/rfc5280.txt
> 3.3 Revocation
> and
> 5.3.1. Reason Code
>
> CRLReason ::= ENUMERATED {
> unspecified (0),
> keyCompromise (1),
> cACompromise (2),
> affiliationChanged (3),
> superseded (4),
> cessationOfOperation (5),
> certificateHold (6),
> -- value 7 is not used
> removeFromCRL (8),
> privilegeWithdrawn (9),
> aACompromise (10) }
>
> If like you say, someone breaks RSA (like NSA ;-), how do we indicate in a standardize way to the WebID community why a key was disabled? Deleting a key cuts off any issues, but if I am trying to validate why Henry posted something "not so nice" about me onhttps://my-profile.eu/ on 11/1/2013, it could have been a hacker who stole his private key. Henry then, with CRL language in his WebID profile could indicate that a particular key was compromised on 11/2/2013 with a "cACompromise". Now instead of guessing, I have an idea that it wasn't probably him. - Erich
>
> True, but in that case, there is no indication that a particular key
> was used by Henry when he auth'd to https://my-profile.eu/ when he
> posted. This mechanism would involve a full traceability of the user's
> actions, on all the services he visited. Maybe we drop it for now and
> open an ISSUE on the tracker, to deal with it once we're done with the
> review.
Unless the public key is kept but flagged as disabled. That would be a
different process though. I was thinking in terms of digitally signed
RDF/data with my WebID. Perhaps you're right, flag it for later. - Erich
>
> Andrei
>
>
>
> On 09/06/13 3:22 PM, Andrei Sambra wrote:
>> On Fri, Sep 6, 2013 at 9:14 PM, Erich Bremer <erich@ebremer.com
>> <mailto:erich@ebremer.com>> wrote:
>>
>>
>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
>>
>>
>> 2.2.1.1Cryptographic Vocabulary
>>
>> "The following properties/should/be used when conveying the
>> relation between theSubject
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#dfn-subject>and
>> his or her key, withinWebID Profile
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#dfn-webid_profile>documents:"
>>
>> Shouldn't "SHOULD" be "MUST"? - Erich
>>
>>
>> Good question!
>>
>> I've been recently thinking about that section. I think SHOULD is
>> ok for now, as long as we mention that WebID-TLS supports
>> multiple encryption algorithms that are available for TLS.
>>
>> And now...what if tomorrow we find out that a new attack
>> completely breaks RSA? This is probably a question that we can
>> ask once we move to a WG.
>>
>> Andrei
>>
>>
>>
>>
>> On 09/05/13 9:52 AM, Henry Story wrote:
>>> Dear WebID Community Group,
>>>
>>> we now have three specs up on github here
>>>
>>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
>>>
>>> All editors think that it is time to publish a new version
>>> on the W3C WebID Incubator space, to finalise the distinction
>>> between WebID, WebID-TLS, and the cert ontology.
>>>
>>> So we would like to be able to publish the specs above
>>> at the following location, by Friday 20 September 2013
>>>
>>> http://www.w3.org/2005/Incubator/webid/spec/
>>>
>>> We would be very happy to receive feedback from
>>> the community before doing so. If you can spot
>>> any errors or improvements please let us know,
>>> we'll do our best to get them in before publication.
>>>
>>> Thanks,
>>>
>>> Henry Story
>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
>>
>
>
Received on Friday, 6 September 2013 19:56:26 UTC