- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 10 Sep 2013 14:29:41 -0400
- To: public-webid@w3.org
- Message-ID: <522F6515.8060200@openlinksw.com>
On 9/10/13 3:00 AM, Henry Story wrote:
>
> On 6 Sep 2013, at 21:48, Andrei Sambra <andrei.sambra@gmail.com
> <mailto:andrei.sambra@gmail.com>> 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
>>
>
> This is issue-67
> http://www.w3.org/2005/Incubator/webid/track/issues/67
>
> Currently keys have been mathematical objects ( like numbers ). Adding
> a time stamp
> would turn them into time slices of mathematical objects. This would
> require then changing
> all implementations to look for time slice information in their
> verficiation algorithms.
>
> An X509 Certificate seems to give a validity time to the certificate
> itself. (Two certs
> could have the same keys and different "Not After" values. ), which is
> a bit similar
> to the HTTP valdiity times of a representation.
>
> We could add a revocation mecanism quite easily by adding a
> cert:revoked relation such as this
>
> <#i> cert:revoked [ a :Revocation;
> cert:revokedKey <#key1> ;
> cert:fromDate
> "2013-08-12T01:12:12"^^xsd:dateTime ;
> :comment "Lost my computer";
> ] .
>
> These revocations could then by subtyped for different reasons for
> revocations.
> Of course the user should remove the cert:key relation from his WebID
> Profile, since that
> establishes the current validity of the relation between the agent and
> the key ( as specified
> by the HTTP validity time of the document of course )
>
> Note how nothing in the cert ontology stops one from naming keys.
Why go through all of that when you can just remove the public key data
in question from your profile document? Stealing your computer and
impeding your ability to access your profile documents, in this use-case
scenario, isn't alleviated by what's outlined above.
I see utility in this kind revocation when dealing with WoT membership
e.g., revoking membership, for a plethora of reasons, starting from a
specific date. Even in this scenario, this is more to do with ACLs than
an actual authentication protocol.
Kingsley
>
> Henry
>
>> 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.
>>
>> 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/
>>>>
>>>>
>>>
>>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 10 September 2013 18:30:10 UTC