Re: Any drafts for IMAP4/TLS and/or POP3/TLS

Hi Chris,

> > Third, I think some language is necessary with respect to X.509
> > certificate profiling.  Probably these five things would suffice:
> >
> > One could argue that TLS or PKIX should address this fourth set
> > of issues, but I'd say otherwise.  All of them are cert policy
> > issues which affect interop for this application, but perhaps
> > not for others.
> 
> My general inclination is that most of this stuff really belongs in the
> TLS specification, as part of the definition of the
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite.  Otherwise this would have
> to be duplicated in every profile, which seems silly to me.

As I said originally, I think these aren't appropriate to standardize
at those lower levels.  But I agree that if this is done "right", it'd
be easily shared by multiple protocols ... if I understand the goals
and constraints correctly!


>	  Is there
> really a reason to use TLS without binding the certs to the hostname, or
> using the same algorithm to certify the key that the key uses to sign
> values? 

Yes on the first -- any class of user-to-user applications will have a
CN= field that doesn't include a hostname!  It's only user-to-host
style applications which could adopt a CN=hostname policy.

Yes also to the second, and in fact my note gave an example of a
situation (with a CA) where it was desirable.  Another example is found
in the DH_DSS key exchange algorithm, where the key in the certificate
can't be used to create digital signatures.  (Similarly, DH_RSA.)

One could make the general point that the trust hierarchies identified
by the cert chains are completely unrelated to the technical issues of
of which technologies a given CA happens to use right now ... when folk
start to deploy public keys with elliptical-curve DSS variants, it'll
be important to be able to meld those keys into the existing trust
hierarchies rather than force creation of a new root CAs.


>	 I'm not trying to brush these issues under the carpet because I
> agree they're very important, but I'd prefer these issues were addressed
> in one place, as the vast majority of TLS profiles will have exactly the
> same requirements.

I sympathize, but that place shouldn't be TLS.  And since you want this
to be a standards document, such issues either belong in an application
profile for TLS, or belong in some other standards-track document.


> In addition, I know very little about X.509 certs (I'm an IMAP/POP guy --
> not an OSI/ASN.1 guy), so I don't believe I could write good text to
> address the issues you've raised.  If you would be willing to write text
> describing a TCP/TLS profile for the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> cipher suite, I'm sure we'll be able to find a home for it.  If the TLS
> group doesn't want it, it could either be a standalone document which TLS
> profiles can reference or I'll drop it in this profile if people think
> that's a good idea.

I'll see if I can find time to craft some text, aiming to be as generic
as possible.  When it's available we can figure out if it's realistic
to have it be a separate document.  In fact, I can't think of anything
there that the HTTPS profile shouldn't use ... the main body of the text
could say "here is the generic TLS profile", then the HTTPS spec might
well be a single page document saying "it uses that profile".


> > Arguably such a set of parameters should be in the TLS spec.
> > But, it's not there now, and not looking to be.  Perhaps it'd
> > be approprate as a separate informational RFC, rather than as
> > part of either the IETF's TLS or {IMAP4,POP3}/TLS specs.
> 
> It sounds like the sort of thing that would make a useful informational
> RFC.  

Or, put it into a "generic TLS profile" as a "MAY" reccomendation.

- Dave