Subject: RE: [Sip] more SMIME comments

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 21 Feb 2002 03:33:20 -0600

Thanks for these last-minute nits, Mike. The appropriate changes will be
applied. Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 9:26 AM
> To: [email-masked]
> Subject: [Sip] more SMIME comments
> 
> 
> 
> 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.

Yeah, we talk pretty casually about having the 'subject' of the certificate
be an identity. I think EKR spoke to this already in another mail; I believe
2633 characterizes this. Maybe we should at least once in the spec not speak
casually about this.

> 
> 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.

Agreed that it won't be reasonable for all user agents. For the same reason,
managing a large set of root certificates in a tiny UA is infeasible. We
need to strike a balance somewhere in the middle. Maybe smallish handsets
will only have room for a few certificates (like, 10 seats worth). Maybe
some handsets won't be able to use it at all. I long for the day when an
iPaq-strength handheld wireless device gets provider subsidies like
cell-phones do. I'm not sure if we really need to add anything to the text
to capture your thinking here, though.

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

This is a good question, and represents something that it is difficult to
address in the text. We obviously can't call out to CAs by name and say you
MUST or SHOULD buy their products. I asked around and got a general sense
that you could say "well-known" certificate authorities comparable to those
that supply root certificates for web browsers should be used for TLS/IPSec.
I'm not really sure how to get any better leverage on this. Then I suggested
that these be reused for S/MIME. Getting root CAs specifically for S/MIME is
a MAY now.

> 
> 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.

I appreciate your cracking down on casual language. We'll hit these points.

> 
> 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.

The user could reject the request. Hang up and call back, maybe. It is a
good point that we should probably recommend some behavior to users here.

I agree that a change in certificates is not necessarily a security breach,
but I think it is certainly a cause for alarm if it is unexpected.
Revocation for self-signed certificates is clearly a pretty ad-hoc matter;
we do recommend that users keep certs for a long time, but there isn't much
you can do if some new Outlook virus posts your private key to
rec.humor.funny. You have to make a new key and re-establish trust with any
users who had your old key.

> 
> 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
> 

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2002 07:49:42 -0800 (PST)

> to capture your thinking here, though.

   Well, on the one hand we have a general requirement
   that we build a protocol suitable for SIP widgets
   of all shapes and sizes, and on the other hand we
   know that some shapes and sizes won't be able to
   provide this feature. What's wrong with picture?
   
   Unlike code footprint which is a one-time expendature,
   this is, in fact, unbound. What that says is that the
   proposed mechanism is either inappropriate for the
   requirements, or that the problem is generally
   infeasible. I don't think it's the latter because
   it clear that you don't need to store per client
   anything for, say, IKE/TLS. Thus I guess we're left
   with wondering whether this is the right answer for
   SIP.

   And spare me that "good enough" argument again. That
   has never been the standard around here before.

 > users who had your old key.

   Again, this points to a structural problem with the
   mechanisms you've defined. The answer to a listing
   tower is not to get everybody to move to one side.

	    Mike