Re: Matter of DN and what's possible

On 1/8/12 3:13 PM, Peter Williams wrote:
> First, the API you are refernecing only gives access to the first URI. 
> And yes, by ISO smenatics, its a name. Its one of a number of 
> alternative names.
>
> In the issuer policy referencedin the certPolicy extensions, where the 
> policy on the end of the referring URI MAY BE METADATA that instructs 
> a "cert using system:, it can say whether as authority it intends for 
> "alternativeness" of a SAN collection to means one of the owl:sameAs 
> meanings. It can say whether URIs in the URI bag are equivalent, 
> whether all names of all names forms, are equivalent.
>
>
> Second, the v3 cert already has an extension address locator, for the 
> "endpoint" at which one shoud expect a MIME typed stream to be 
> returned. Tt avoid the rat trap, is uses the notion of access method: 
> http://www.ietf.org/rfc/rfc3280.txt 4.2.2.2  Subject Information Access
>
>  note PKIX does not defined "information services/ endpoints" for end 
> user certs (only certs that are marked CA).
>
> In this community (where we do not distingush between CAs and EE - 
> since everyone is a potential self-signer and thus a CA), it is quite 
> acceptble to use the provided locator tag. Simply mark one's cert with 
> the basicConstraints isa CA. Then include the access locator (with the 
> file locator oid given in the spec).
>
>
> Alternative, we get a MIB from IANA, and define our own OID, say it 
> has the very same semantics as PKIX defined for CAs... except it 
> servers for non-CA certs (formally).
Peter,

What's critical here is our ability to be clear about use of Identifiers 
in a cert. such that the Name and Address roles are distinct. Doing this 
via DN (valid) but remains controversial here. Doing it via SAN valid, 
but some still don't grasp that these valid *magical* properties of URIs 
are rife with confusion since the URI abstraction itself remains 
partially understood by the majority.

What we need to get people to understand somehow is the fact that you 
can have a URL (a Locator) and a generic URI (Name) in a cert such that 
publishers can make descriptor resources for cert. subjects -- using 
URIs as subject names --  and then publish to network resources 
addresses identified using URLs.  Doing this reduces publisher tedium 
inevitably introduced by  Linked Data nuances re., de-referencable URI 
based names.

Irrespective of what happens to WebID, we are going to keep and ensure 
this fidelity in our verifiers.

BTW -- what I am describing is how you end up with a SPARQL URL 
(shortened using a shortener of your choice) in an x.509 and WebID 
verification sings along in the most unobtrusive manner imaginable. The 
only time a SPARQL URL (and optional use of a shortener) creates 
problems is when the mandate is that the SAN can only have 
de-referencable URI based names. The URI abstraction always implies 
scheme and role agnosticism albeit not always visible and comprehensible 
to all URI users.

seeAlso from http://www.ietf.org/rfc/rfc3280.txt re. the implicit 
possibilities for Names and Addresses in a SAN with  values that 
constitute a composite key:

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


    GeneralName ::= CHOICE {
         otherName                       [0]     OtherName,
         rfc822Name                      [1]     IA5String,
         dNSName                         [2]     IA5String,
         x400Address                     [3]     ORAddress,
         directoryName                   [4]     Name,
         ediPartyName                    [5]     EDIPartyName,
         uniformResourceIdentifier       [6]     IA5String,
         iPAddress                       [7]     OCTET STRING,
         registeredID                    [8]     OBJECT IDENTIFIER }

    OtherName ::= SEQUENCE {
         type-id    OBJECT IDENTIFIER,
         value      [0] EXPLICIT ANY DEFINED BY type-id }

    EDIPartyName ::= SEQUENCE {
         nameAssigner            [0]     DirectoryString OPTIONAL,
         partyName               [1]     DirectoryString }

4.2.1.8  Issuer Alternative Names

    As with 4.2.1.7, this extension is used to associate Internet style
    identities with the certificate issuer.  Issuer alternative names
    MUST be encoded as in 4.2.1.7.

    Where present, this extension SHOULD NOT be marked critical.

    id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }

    IssuerAltName ::= GeneralNames

-- 

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