Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml

["John R Levine" <[e-mail]>]

> Security model ... I'm a big confused by the use of HTTPS and DNSSEC. 
> They both seem unneeded if the idea is a certificate is more or less 
> self securing and public

1The security model is deliberately vague.  Some people believe that if a 
domain publishes S/MIME certificates for its mail users, that cert is 
authoritative.  If you do, the HTTPS and DNSSEC provide a chain of trust.

If we think that publishing a signed TLSA for the S/MIME signing cert is 
adequate, we can ditch the rest of the DNSSEC, although https is best 
practice these days for anti-snooping purposes.

> The API. I'd like to see it clearly work for all types of URIs including email.

Please, no, not death by overgeneralization.  We have at least one large
mail system that wants to publish certs for its mail users.

> It also seems that perhaps a parameter that directly indicated the 
> returned type like x509, pgp, etc would be a better API design that 
> using uri vs email to indicate if it was x509 or pgp.

This is essentially a profile of RFC 5280, which has been a standards 
track RFC for eight years.  Let's not invent any more new stuff than we 
have to.

> I don't get why the Name Matching parts happens.

Because email addresses are fuzzy.  On some systems bobsmith@example and 
bob.smith@example and/or bobsmith-ext@example are equivalent, while on 
others they aren't.  (A brief review of RFC 5321 will remind us that no, 
there is no such thing as a canonical version of a mail address.)  So this 
says the cert lookup should use the same fuzz that the mail system does.

> I think what you are really talking about here designing a HTTP REST 
> based API for retrieval of certificates (and it happens to have an SRV 
> entry). That seems to be an idea worth discussing.

No, once again, it's just a profile of RFC 5280.

R's,
John