On 10/30/10 11:53 AM, Jim Schaad wrote: > Peter, > > 1. I had an email problem so probably missed the discussion, however > I do not understand the current text for the example of a delegated > domain. I would suggest text, but as I am running on I don't > understand that is not possible. Is this supposed to be some type of > mapping that says the domain X is really the domain Y?
One example might be that [email protected] configures her email client to connect to mailhost.example.com instead of just example.com. Another example might be connecting to isp.example.net for example.com. Again, these would be explicitly configured in an email client. > 2. In the definition of reference identifier > s/optionally/optionally/ Fixed. > 3. In section 2.1 you have the sentence "This dimension matters > most for certificate verification." Would this be more appropriate > as s/verification/consumption/ ? The process of certificate > verification does not really care, but the name matching does. Done. > 4. In the definitions you might want to add one for "automated > client" to match "interactive client" I think we already have that in version -10: automated client: A software agent or device that is not directly controlled by a human user. > 5. On page 20, the following text exists: For an interactive client, > it is strongly encouraged that each reference identifier SHOULD be > based on the source domain provided by the user and SHOULD NOT be > based on a derived domain (e.g., a host name or domain name > discovered through DNS resolution of the source domain). > > I am not clear why this is important for interactive clients and not > for automated clients. Good point. Changed in my working copy to: It is strongly encouraged that each reference identifier in the list SHOULD... > 6. In section 4.6.2 - I am disappointed that the concept of checking > that the context is either the same or similar is not also included > in this check. I think this is an important concept. Agreed. I propose adding the clause "including the context as described under Section 5.1", as follows: If the client does not find a presented identifier matching any of the reference identifiers but the client has previously pinned the application service's certificate to one of the reference identifiers in the list it constructed for this connection attempt (as "pinning" is explained under Section 1.5), and the presented certificate matches the pinned certificate (including the context as described under Section 5.1), then the service identity check succeeds. Thanks for your feedback. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
