Robert Relyea wrote:
> Sorry, my last response went out before I was finished....
>
>
>>
>> >
>> > Here's what communicator 4.x does today (for reference):
>> >
>> > If the email check fails, the signature is labelled invalid. The
>> email address in
>> > the cert must match the from line of the e-mail.
>>
>> Unfortunatly this is spoofable, but probably nothing better.
>
>
>
> Spoofable meaning? That I can claim the email address does not match the
> identity I claim to be, or that the email address itself is spoofable.
I was simply pointing to the truth that the 'From' line need not have
any relationship to the point of origin of the email.
> What the signature is saying is "This message was signed by the person
> whose email address it claims to have come from." You are right that it
I am not familiar with the Mozilla requirement for selecting a cert to
be used for signing. But I assume it will only use a cert that 1) has
signature key useage extension and 2) has a 'From' entry that matches
some internal field of the certificate.
Given these two, the signature means that the signing key was available
through an existing condition (check once upon opening the cert7db) or
a security token (passphrase) was supplied that allowed the security
container to be accessed. But says nothing about the person initiating
the sending of the mail. The security of this model is a full topic by
itself.
Now, why is #2 above necessary? It would seem to be a logical choice
if there is only one, but what if there are 2 signing certs, one with
and one without an email (don't say it can't happen because Mozilla
wouldn't allow that)? Does the uses choose? Can a default be set for
this subject? ....
> doesn't guarantee that this person really sent you the message, but it
!! or dirceted it to be signed !!
> does say that the email address and the signer are the same.
I started to decompose a signature just now, but it too much
trouble while writing this. I assume that the 'signature' includes
the From, To and Subject lines and has some way to ignore the
reformatting that may happen. Why does a signer need to have an
email address at all? They wanted to 'sign' the message, but it
doesn't necessarily follow that it needed to be sent from
just that one place. The signature affirms the person, not
the address (or at least it should).
>
>
>>
>> > e-mail addresses and certificates match one for one. That is one
>> certificate
>> > (actually one set of certificates matched by subject) match
>> ? 'subject' = CN or DN?
>> All certs in a set must have same email?
>
>
>
> Subject == DN, not CN, Subject is how certs are grouped into a single
> personality.
>
As you state below, each CA mungs up the DN with it's own OU, so that
no subject can exist that has multiple certificates from differen CA's.
This sounds like a Business Model designed to lock the user to a single
CA. Lacks flexability. Constrains the user (for his own good and
confusion). *FLAME* ....
>
>>
>> > one for one to email address. Communicator can not handle more than
>> one certificate
>> > (subject)* per email address, nor can it handle multiple email
>> addresses for
>> > pointing to the same certificate (subject)
>> .
>> This means that Bob Lord's addressbook entry cannot contain email
>> certs for
>> '[EMAIL PROTECTED]' as well as '[EMAIL PROTECTED]'?
>
>
>
> No, it means Bob Lord can't have a single cert with both
> [EMAIL PROTECTED] and [EMAIL PROTECTED] support for multiple email
> addresses supported by multiple certs is already there (side note: did
> we just generate a whole lot of spam for the poor soul who has
> [EMAIL PROTECTED] ;().
>
>
>> > *certificate (subject) means a collection of certificates which
>> make of a single
>> > personality all sharing the same subject DN. 90 % of the time it
>> means a
>> > single cert.
>>
>> DN uniqueness is not required across CAs. I could have exactly the
>> same
>> DN on Verisign and Baltimore certificates, and they could have
>> different emails.
>> Uniqueness is only within a single signing authority.
>
>
>
> DN Uniqueness is required 'locally'. 'locally' for the internet is
> worldwide. If Baltimore and Verisign started issuing certificates with
> the same DN, the current internet infrastructure would not handle it.
> Not version of Netscape, and I suspect no version of IE as well would be
> able to deal with this.
The 'structure' is based upon a heirarchical data store and the
certificates position within that heirarchy. The store is rooted
at the CA. I can see where the issuing CA identifier (DN, thumbprint,
or whatever) in addition to the individuals DN should make a unique key.
The idea of embedding the CA in an RDN means that two certs for the same
person (real world entity) will never compare as equal. Using this
uncontrolled RDN (OU field) in some arbitrary location in the DN
string seems to cry out for failure.
>
> Why? because of intermediate CA's. DN's not only define email certs, but
> also CA's. To make cross certification work, you have to equate to certs
> with the same DN but different subjects. This means that within a
> locality (that is within the domain in which these certs can spread),
> DN's must be unique.
>
> You will notice that in fact Baltimore and Verisign do not issue certs
> with the same DN both CA's add a organization string in the DN which is
> unique to them. (enforceable in this case under trademark law;).
>
>
>> >
>> > ----------------------------------------------------------------
>> > What our goals for mozilla are:
>> >
>> > If the email check fails, the signature is labelled invalid. One of
>> the email
>>
>> And as such, is the user consulted to see if they wish to store
>> it anyway?
>> Is it possible the user wants that cert stored anyway?
>
>
>
> Good questions. we need a balance between doing things automatically and
> doing what the user would want. We don't want to put up dialogs for
> every little thing, but we also want to give user more control.
>
I really think I (as a user) should be able to associate any certificate
with any address book entry of my choosing. If *I* want a cert with
encryption extension and a DN of "....Billy Bob" associated with my
brother Jim, then the software shouldn't stop me. It probably shouldn't
do it without asking, but it should be possible.
I should be able to sign my mail with a cert that has no e-mail address
at all in it. I am vouching for the content, not declaring where you
should send the spam after reading it. And if it has an encypherment
extension, you should be able to send me encrypted content at any
e-mail address!
>
>>
>> > addresses in the cert, if any exist must match the from line of
>> the email
>> > sender. If no email addresses exist, a mapping of cert to email
>> addresses from
>> ^ in cert?
>
>
> yes
>
>
>> > some trusted source (directory/database) is attempted. If none
>> exist at all
>> ^ specified how? from the bad cert? from user?
>
>
>
> TDB. Suggestions? It would most likely be some configuration option, but
> what should the default case be?
Since we(the CA's) have violated the DN by inserting an OU for
the CA, there can not be a central registry that can organize
all the entries based upon the DNs. Without the OU=CA entry, at
least all of the "Some Random Name" subjects could be grouped.
But then; signing something doesn't mean that I want you to have
any email address at all. If I did I would have sent or included it.
Why does this all have to be tied together?
>
>
>> Did you see the announcement this week that the DoD just shipped
>> the first
>> 600,000 (out of 6 million?) Smart cards to be used as the military
>> Common Access Card. And from the "X.509 Certificate Policy for the
>> United Stated Department of Defense" (version 5.2), section 6.1.7
>> we find:
>>
>> "Public keys that are bound into certificates which assert the
>> CLASS 2,
>> CLASS 3, or CLASS 4 assurance policies shall be certified for
>> use in
>> signing or encrypting, but not both,..."
>> Looks like they issue 2 different certs, the one you sign with
>> cannot do encryption.
>
>
>
> I didn't see the announcement, but I am familiar with this particular
> deployment. The dual key system the DOD uses is becoming more common in
> enterprise deployments, and has affected our design. This is the basic
> reason for grouping certs by personality. The signing cert and
> encryption cert would share a DN. We know which we would use based on
> the key usage attributes of the cert.
The DoD certs will have some unique RDNs. As well as numbers appended
to the end of the users name.
This also presents the problem that the CA is not part of the current
list of trusted CAs. And most people won't know where or how to
obtain the root cert. That will leave them with simply trusting the
certs blindly...
>
>
>
