Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt

["Tom Gindin" <tgindin@xxxxxxxxxx>]

      Russ:

      Of course I have no objection to mentioning a preference for
subjectAltName over subject for e-mail addresses.  I just thought that
anybody actually implementing something which extracts e-mail addresses
from certificates would be helped by knowing all the places which are used
in large numbers of certificates, not just the approved ones.  In the
earlier wording ("an rfc822Name attribute") I wasn't sure whether
implementors would interpret this as the rfc822mailbox directory attribute
or the rfc822Name component of GeneralName, anyway.

            Tom Gindin

Russ Housley <housley@xxxxxxxxxxxx> on 01/02/2003 02:27:28 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    ietf-pkix@xxxxxxx, jjacoby@xxxxxxxxxxxxxxx,
       pgut001@xxxxxxxxxxxxxxxxx
Subject:    Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt


Tom:

RFC 3280 says that subjectAltName extension using the rfc822Name is the way

that an email address SHOULD be included in a certificate.  I would like to

see the text reinforces this, but says that there are certificates that use

other placements.

Russ

At 07:06 PM 12/23/2002 -0500, Tom Gindin wrote:


>       How about mentioning the other two normal ways of storing the email
>address: "This is typically stored in the certificate either within the
>subject DN as a value of one of the attributes rfc822mailbox or
>emailAddress, or in the subjectAltName extension using the rfc822Name
>choice of GeneralName".   I've personally never seen anyone use any other
>way than those three.
>
>             Tom Gindin
>
>
>pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)@mail.imc.org on 12/20/2002
>09:10:32 PM
>
>Sent by:    owner-ietf-pkix@xxxxxxxxxxxx
>
>
>To:    ietf-pkix@xxxxxxx, jjacoby@xxxxxxxxxxxxxxx
>cc:
>Subject:    Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt
>
>
>
>Jeff Jacoby <jjacoby@xxxxxxxxxxxxxxx> writes:
>
> >Is it necessary to require an exact match for all attributes,
particularly
> >for such attributes as the email and name attributes?
>
>In a word, yes.
>
> >For example, I'm looking for the cert for Bill Williams, but I don't
know
>if
> >the common name is "Bill Williams" or "Will Williams" or "B. Williams",
>etc,
> >so I might like to try a search on just "Williams"
>
>How would you specify this?  You'd need some sort of general-purpose
>pattern-
>matching mechanism and then a means of mapping it to every possible
backend
>that might be used to implement the lookup.  The draft specifies a
>universal
>interface to (conceptually) a basic key-and-value lookup engine, which
>doesn't
>extend to general pattern-matching.  If you need anything more than this
>(for
>example searching on compound attributes and similar things) you should
>really
>use LDAP.
>
> >Secondly, the entry for email attribute indicates the value as:
> >
> >  "Subject email address contained in the certificate, typically as an
> >   rfc882Name attribute
> >
> >Is it necessary the email attribute be from the certificate.  Is it a
> >reasonable or likely situation that a certificate store might use the
>email
> >address as an database index even though it's not actually in the
> >certificate?
>
>I'd never thought of it being done like that, but I can easily change the
>text
>to accomodate it.  How about:
>
>   Subject email address associated with the certificate.  This is
typically
>   stored in the certificate as an rfc882Name attribute.
>
>Peter.