Russ,
There was a big discussion about #1. -- It is a question not a
statement. The result was that this should not be required (at least
for non e-mail applications).
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Russ
Housley
Sent: Tuesday, July 29, 2003 2:08 PM
To: Blake Ramsdell; ietf-smime(_at_)imc(_dot_)org
Subject: RE: RFC2632bis and subjectAltName
Blake:
I do not think that the specification does #1. SHOULD is
very different
than "required."
Russ
At 02:04 PM 7/29/2003 -0700, Blake Ramsdell wrote:
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Russ
Housley
Sent: Tuesday, July 29, 2003 9:14 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RFC2632bis and subjectAltName
The document says:
The email address SHOULD be in the subjectAltName extension
This is exactly the same thing that RFC 2632 says.
If the certificate does not bind the public key to the email
address, how is this done? Should we mandate an alternate
mechanism? Or, should we
change "SHOULD" to "MUST?"
I think that the current spec tries to address at least two issues
here:
1. Is it required that an email address be present in the certificate
2. If the email address is present, where should it be
located (subject
DN vs. subjectAltName)
Are you asking about:
3. How do we understand if the CA was putting the email
address in the
certificate purely for informational reasons vs. actually doing some
work to make sure that the public key "belongs" to that email address
If so, I have no idea -- it's "do what PKIX says" in this case.
Blake