ietf-smime
[Top] [All Lists]

Re: The address-in-certs issue

1998-01-06 20:15:53
Paul Hoffman / IMC wrote:

Nice to see you back from vacation, John.

At 02:33 PM 1/6/98 -0800, John Gardiner Myers wrote:
In the message to which I was replying, Paul Hoffman was disagreeing
with this very point.  He was espousing a position that it was OK for
the S/MIME specification to allow a conforming CA to issue certs
containing only DN's, yet allow UA's to only recognize RFC822 addresses.

I never said that. What I said was, unless we specify that this part of the
cert spec relates specifically to Internet mail, requiring RFC 822
addresses with no semantics is no more useful than requiring any old string
with no semantics.

For the record, you stated in your message of 22 Dec 97 16:40:42 PST
that the failure resulting from the abovementioned situation "is due to
the presentation problem, not to the protocol".  In your followup
message at 21:32 you said of the noninteroperation: "That's out of
scope."

John, your argument has changed over the thread, and where you are now is
much clearer than when you started off.

I've read over my old posts and don't think I've changed position. 
What's probably confusing things is that there are three separate issues
being argued:

ISSUE1) Does S/MIME need mandatory minimum identifier syntax
requirements?

ISSUE2) Assuming yes to ISSUE1, what are the requirements for Internet
Mail?

ISSUE3) What relation, if any, do identifiers in the cert have with an
address in the From: header?

I've unfortunately been arguing both ISSUE1 and ISSUE2 in the same
messages.

At the risk of pissing you off even
further, let me try to summarize what I believe you are now saying:
- We should define the cert contents for certs passed in S/MIME messages
over Internet mail

Close.  To break this down more precisely, from my message of 12/22/97
18:09 PST:

JGM1) In order to interoperate, each application of S/MIME must specify
mandatory minimum idenitfier syntax requirements on CAs and receiving
UAs, such that every conforming cert has identifiers interperable
(subject to policy) by every conforming UA.

JGM2) The mandatory identifier syntax requirements of Internet mail
should be specified in a base S/MIME document.

JGM3) Applications other than Internet mail may profile S/MIME to change
these identifier syntax requirements as necessary.

- In these certs, the identifier must be an RFC 822 name, and cannot be a
DN (subject name null, subjectAltName must have at least an RFC 822
identifier in it)

The mandatory identifier syntax requirements for Internet Mail should be
that the CA is required to include at least one RFC 822 name and the UA
is required to be able to interpret and display RFC 822 names in an
intelligible manner.

CA's may include additional identifiers of other syntaxes, be they DN's,
Credit card accounts, IP addresses, Wampums, Foma, or Pantaloons.  UAs
may interpret and/or display such additional identifier syntaxes.

- That identifier has some semantics. Someone creating a cert must follow
certain rules about the parts of the RFC 822 name. Someone receiving the
cert can be sure of certain things about the RFC 822 name and use that
information to make further inferences about the signer.

The above statement is true for ANY identifier, regardless of syntax.
 
I'd like to request that you (John) write these out as a specific wording
changes for the certs draft so that we can talk about a specific, static
proposal.

Well, we have multiple issues with dependencies between them.  Can we
get agreement on JGM1 through JGM3 before tackling ISSUE2?

I'd especially like the wording on the semantics of the RFC 822
addresses, since this was a point of concern from other people on the list
and one that was not clear in your early posts.

An addr-spec is a specific Internet identifier that contains both a
locally
interpreted string followed by the at-sign character ("@", ASCII value
64)
followed by an Internet domain. The locally interpreted string is either
a
quoted-string or a dot-atom. If the string can be represented as a
dot-atom
(that is, it contains no characters other than atext characters or "."
surrounded by atext characters), then the dot-atom form SHOULD be used
and the
quoted-string form SHOULD NOT be used. Comments and folding whitespace
SHOULD
NOT be used around the "@" in the addr-spec.

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

domain-literal  =       [CFWS]
                        "[" *([FWS] (dtext / quoted-pair)) [FWS] "]"
                        [CFWS]

dtext           =       NO-WS-CTL /     ; Non-white-space controls

                        %d33-90 /       ; The rest of the US-ASCII
                        %d94-127        ;  characters not including "[",
                                        ;  "]", or "\"

The domain portion is a fully qualified identifier for an Internet host.
For
example, in a mailbox address, it is the host on which the particular
mailbox
resides. In the dot-atom form, this is interpreted as an Internet domain
name
(either a host name or a mail exchanger name) as described in [DNS]. In
the
domain-literal form, the domain is interpreted as the literal Internet
address
of the particular host. In both cases, how addressing is used and how
messages
are transported to a particular host is covered in the mail transport
document
[SMTP]. These mechanisms are outside of the scope of this document.

The local-part portion is a domain dependent string. In addresses, it is
simply
interpreted on the particular host as a name of a particular mailbox. In
a
message identifier (described in section 3.6.4), it is an identifying
string
that is unique to a message generated on a particular host. It is
otherwise
uninterpreted in this standard.

[The reference to section 3.6.4 is to the document
draft-ietf-drums-msg-fmt-03.txt]


<Prev in Thread] Current Thread [Next in Thread>