W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

RE: broken turtle

From: Peter Williams <home_pw@msn.com>
Date: Thu, 22 Dec 2011 18:29:07 -0800
Message-ID: <SNT143-W584BF4716715EAA6B5F18092AB0@phx.gbl>
To: <kidehen@openlinksw.com>, "public-xg-webid@w3.org" <public-xg-webid@w3.org>

can I assume now folks have lost their fear of the evil ASN.1,  that we can add 2 more properties from the implied vocab of certs? just as SubjectAlternativeName  is a multi-value property, of type&format URI, so AuthorityInfoAccess and CRLDistributionPoints are compound types (with trivial URI primitive types/formats), no more complicated than the model Henry wrote up for cert:key. I'm sure there must be a way in RDF-land not to describe something, but just say: its opaque (but distinguished opaque). In 1980s ASN.1 legacy, its called a tagged ANY. Typically its locally tagged, but you can declare it with a global tag, if you must (oid:x.y.z#1).  NSA/DoD's first attempt at a secure messaging spec in ASN.1 was done really poorly and laughably poorly (since the guy knew nothing about proper style). he just took a bunch of legacy bit string formats, and stuffed an ASN.1 global tag on the front of each, describing each thereby as a opaque bit string! Fortunately, folks learned quick to model and describe properly. Engineering duly followed.    AuthorityInfoAccess [
caIssuersaccessLocation: URIName: 
]] SubjectAlternativeName 
http://rapstr1.blob.core.windows.net/ods/user.ttl#me  CRLDistributionPoints 
]]Date: Thu, 22 Dec 2011 21:10:53 -0500
From: kidehen@openlinksw.com
To: public-xg-webid@w3.org
Subject: Re: broken turtle


    On 12/22/11 8:56 PM, Peter Williams wrote:

        my new cert (old key) with turtle on azure cloud blob service:
        site reports ok. REport 1 URI, correctly.


          my old cert (old key) with RDFa
            on blogger page : site reports ok. Only reports 1 URI.
          ODS cert/key/proxyURI with proxied page (for an original
            twitter account): site reports fail
    Ah! There are some issues with the Proxy URIs. Myself and Henry had
    a quick one on one session and found two issues. One relates to
    across the wire serialization which we have to fix. The other is a
    niggling issue re. cache invalidation, but you can work around it by
    adding the following to the ProxyURI: ?@Lookup@=&refresh=clean 
    after you place the ProxyURI in your browser's address bar. 


    The simple test is this, if you don't see the cert. fingerprints in
    the page that is returned to your browser you know that the
    validation will fail due to incomplete graph. 





    One of my ProxyURIs:
    http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen .


    Document URL to which the Name above resolves:


    Forced refresh:


    Then retest and it will work, as long as you can see the fingerprint
    in the page (human readable descriptor) returned to the browser. 





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

Received on Friday, 23 December 2011 02:29:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC