[foaf-protocols] WebID spec: Subject Alternative Name extension

Seth Russell russell.seth at gmail.com
Fri Jul 16 16:49:03 CEST 2010

Well i'm not requesting that the specification "mandate" the disclosure of
an email address.   I am just requesting that  if the customer wants to give
the merchant their email  address, then  the specification standardize how
that is done so the merchant can reliably get it.

A little background is needed here.   We always have the chicken or the egg
problem to get a protocol flourishing: no merchants will bother to
implement, if there are no customers out there to use  it,  and no customers
will bother to get certificates if there are not places that use them.   By
kicking this one down the road to  some geeky foaf document will make the
chicken and egg paramount.   Look there are zillions of merchants and web
sites out there who just need identity and email  to be able to function ...
to do what they are setup to do.   You can give all of those web sites a
very good reason to implement your protocol if you give them the one thing
that dearly need, the ability to communicate back to their customers.

Seth Russell
Alpha testing: tagtalking.net
Facebook ing: facebook.com/russell.seth
Twitter ing: twitter.com/SethRussell
Blogging: fastblogit.com/seth/
Catalog selling: www.speaktomecatalog.com
Google profile: google.com/profiles/russell.seth

On Fri, Jul 16, 2010 at 7:26 AM, Bruno Harbulot <
Bruno.Harbulot at manchester.ac.uk> wrote:

> Hi,
> (Considering that the two threads going on at the moment are getting
> quite "deep", in terms of number of replies and mix a number of issues,
> could we start a new thread per issue? Please start a new thread for a
> new issue, don't hit reply to avoid the mail references IDs.)
> This is about what to put in the Subject Alternative Name extension of
> the X.509 certificates we produce for WebID use. (I suppose this could
> be lead to a discussion about other extensions, such as key usage later).
> Here are a few sub-problems:
> - Should there be multiple entries of type URI in the S.A.N. extension?
> - Should there be entries of type other than URI in the S.A.N. extension?
> - Should the S.A.N. extension be marked as critical?
> Here is my current point of view, also based on the on-going threads
> (I'm writing fragments of what I would write in the specification, but
> that will need further passes):
>  > - Should there be multiple entries of type URI in the S.A.N. extension?
> Possibly. We need to think of what this implies in terms of semantics too.
> I would suggest to allow multiple URI entries:
> "The Identification Certificate MAY contain multiple URI entries in the
> Subject Alternative Name extension. The Verification Agent MUST attempt
> to verify at least one of these entries. It MAY verify more than one
> entry. The Verification Agent MUST NOT consider an entry for which the
> verification failed as authenticated, even if other entries have been
> verified successfully."
> Do we then want to treat multiple successfully verified entries as
> owl:sameAs, or should we leave that to the RDF?
>  > - Should there be entries of type other than URI in the S.A.N.
> extension?
> Yes, why not. Note that the allowed types are as follows:
> > GeneralName ::= CHOICE {
> > otherName
> > rfc822Name
> > dNSName
> > x400Address
> > directoryName
> > ediPartyName
> > uniformResourceIdentifier
> > iPAddress
> > registeredID }
> On 16/07/10 14:46, Melvin Carvalho wrote:
> > IIRC, I think the XMPP folks will use JID: too ...
> (That doesn't seem possible according to the X.509 spec, we're talking
> about the SAN entry type, here, not the URI scheme, so that could work.)
> On 16/07/10 15:12, Seth Russell wrote:
> > I think it's very important that the specification standardize some
> > way for a merchant to get a simple email address so that they can
> > communicate back to their customer.  De-referencing a file in an
> > unknown vocabulary to find a simple email address will be a  non
> > starter for almost all merchants who are interesting in using this
> > protocol to identify their customers.
> I don't think we should go anywhere near mandating an e-mail address
> within the X.509 certificate. That's clearly disclosing private
> information.
> However, yes, doing via FOAF with an established format and vocabulary
> (FOAF), why not (should the use want to disclose this, of course.)
> Regarding e-mails in SAN, there are two possible entries:
>   - email:  user at domain.example
>   - URI:    mailto:user at domain.example
>  > - Should the S.A.N. extension be marked as critical?
> Critical is a strong requirement. It means that whatever may have to
> process such a certificate MUST fail if it cannot understand the extension.
> A number of TLS-based applications don't necessarily understand S.A.N.
> We've just had the problem with one of the libraries we use in fact
> (tailored for PKIX). I would suggest not making the S.A.N. extension as
> a requirement for the X.509 certificates we use, although this must be
> allowed of course.
> If something needs to be said, perhaps something like this:
> "The Subject Alternative Name extension MAY be marked as critical in an
> Identification Certificate, in which case any agent processing this
> X.509 certificate, whether-or-not it supports WebID authentication, must
> be able to process it. The Subject Alternative Name extension MAY also
> be marked as non-critical, in which case this X.509 certificate MAY also
> be used for purposes other than WebID authentication, for example, for
> PKIX-based verification."
> Best wishes,
> Bruno.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100716/8d60dc7c/attachment.htm 

More information about the foaf-protocols mailing list