Subject: [Sip] more SMIME comments

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 09:26:24 -0800 (PST)

1) You cannot put RFC 822 addresses into X.509
   distinguished names (DN's). You either need to
   have a mapping function, or place requirements
   in subject-alt-name, etc.

2) The general requirements for a "keyring" for
   non-disk based UA's is, essentially,
   impossible. Unlike what Henning said yesterday,
   use for encryption requires that both the
   distinguished name and the entire public key
   (not a hash!) need to be stored. Considering
   that phones typically receive calls from
   anywhere, the storage needs are unbound. I'm
   willing to believe that this isn't an issue for
   a multi-gigabyte disk. For flash based UA's,
   however, this is an unreasonable requirement.

3) There is no suggestions about what UA's should
   do about root CA's. Why should a particular UA
   install a root cert?

4) in section 22.1 says that you verify with a
   certificate authority. This is misleading as it
   implies something you actively do with the CA.

5) 22.1: you can verify self-signed certificates
   just fine. You just don't know whether you
   trust the namespace.

6) 22.1: you don't verify certificates. You verify
   signatures.

7) A change in certificates stored is not
   necessarily an error. I don't think the
   normative text here is helpful because this
   is probably a revocation issue. As in, the
   UA complains to the user, and the user is
   supposed to do what, exactly? This seems
   loaded with the ability for abuse.

More later.

		Mike

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Rescorla <[email-masked]>
Date: 20 Feb 2002 09:44:02 -0800

>    in subject-alt-name, etc.
The SubjectAltName is the conventional location 
(see RFC 2632 S 4.4.3.).

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Feb 2002 20:01:02 +0200

Michael Thomas wrote:

>    (not a hash!) need to be stored.

I'm not sure why you say we need to store the public
key. Theoretically, you need to store the SubjAltName and a
hash, I think, because on reception you can (hope) to receive
the cert from the peer, and verify the SubjAltName - Certificate -
Public Key - Hash relationship. For sending if you swapped out
the public key you could request the peer to give you that
using OPTIONS, and then do the same verification, and send
the real message. In essence, this is a RTT vs. memory tradeoff.
The current bis text seems pretty clear RTT is prioritized,
which I think I support. Or do we need to clarify some of
this in the text? Or perhaps leave this for low-cost device
implementors to figure out?

I also scanned through the bis limitations text and it
doesn't talk about the replay protection limitation for
S/MIME. This should be added, if it can't be fixed now.
Also, at some point we need to be able to do S/MIME
like functionality e2m, and the current text doesn't
describe how. Well, maybe B2BUAs could be used, but I'm
not sure all text is there yet.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2002 10:29:18 -0800 (PST)

Jari Arkko writes:
 > I'm not sure why you say we need to store the public key.

   Encryption. 

	       Mike