On 2009-06-30 07:39 PDT, Jean-Marc Desperrier wrote: > Nelson B Bolyard wrote: >>> Does this assume LDAP for acquiring the certificate without a signed >>>> S/MIME message? (So it is only relevant in corporate setting?) > >> No. There are many ways to get a cert for an email correspondent. >> There is only one way to get that correspondent's email capabilities in a >> form that Mozilla mail clients can understand, and that is to receive a >> signed email. > > For what it's worth, I've seen that the Microsoft Certificate Server > product includes a sMIMECapabilities attribute directly inside X509 mail > encryption certificates it issues.
Do you have some example certs that I could examine? > This non-standard usage could be interpreted as "I'll make sure any MUA > that I use with this certificate will support at least this level of > security". That seems like a GREAT idea! (This is one of those "why didn't I think of that?" ideas.) > Whilst I don't usually support Microsoft in reinterpreting standards, in > that case I'll make an exception. I see the X.509v3 standard as being infinitely extensible in the area of certificate extensions. Anyone can get his own arc in the OID tree, and then define his own certificate extension using that OID. (You know about Peter Gutmann's certificate with an embedded JPG image of a cat, right? :) If Microsoft has merely taken a DER-encoded object from another standard and has incorporated it into a cert extension, that seems fine to me. I hope they did it in such a way that existing BER/DER parsers of the sMIMECapabilities attribute can just parse the extension body directly. If you could supply a specification for this new extension, I'd file an RFE for Thunderbird/NSS to handle these certs in the intended manner. > After all, even when you respect the standard and put sMIMECapabilities > only inside a SMIME message, nothing guaranties that you'll be using the > same MUA when you read the response. True, although, you probably want to minimize the number of different places that have access to your private key, so you're not likely to have MANY MUAs. But even two different MUAs with different capabilities in enough to make this an important consideration. > It's up to you to make sure that none of the MUA you use makes promises > another of them can't support, which is only a little less dangerous > than including them directly in the certificate. > > Also, it can be said an encryption certificate without the info of what > encryption protocol the holder is ready to use is much less useful. Yes. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
