- From: Peter Williams <home_pw@msn.com>
- Date: Thu, 22 Dec 2011 18:29:07 -0800
- To: <kidehen@openlinksw.com>, "public-xg-webid@w3.org" <public-xg-webid@w3.org>
- Message-ID: <SNT143-W584BF4716715EAA6B5F18092AB0@phx.gbl>
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 [ [accessMethod: caIssuersaccessLocation: URIName: http://rapstr1.blob.core.windows.net/ods/ca.cer ]] SubjectAlternativeName [ URIName: http://rapstr1.blob.core.windows.net/ods/user.ttl#me CRLDistributionPoints [ [DistributionPoint: [URIName: http://rapstr1.blob.core.windows.net/ods/certcrl.crl] ]]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. Example: One of my ProxyURIs: http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen . Document URL to which the Name above resolves: http://id.myopenlink.net/about/html/http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen . Forced refresh: http://id.myopenlink.net/about/html/http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen?@Lookup@=&refresh=clean . Then retest and it will work, as long as you can see the fingerprint in the page (human readable descriptor) returned to the browser. -- 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
Received on Friday, 23 December 2011 02:29:44 UTC