ietf-smime
[Top] [All Lists]

RFC 3183: Domain Security Services

2002-07-12 02:52:24


Hello all,

I think domain security is a great idea, so I'm curious about this RFC's
status.  I saw in the archives that Baycorp's MailMarshall product
implements it.  Are there other implementations existing or in progress?  Is
it likely that this RFC will progress onto the standards track?

As a technical question, RFC 3183 defines a naming convention where an
entity with a certificate for the name 
"domain-signing-authority(_at_)acme(_dot_)com"
is trusted for producing domain signatures on behalf of 
*(_at_)acme(_dot_)com(_dot_)

This convention seems to accomplish the same thing as the name constraints
extension does for CAs: it gives an entity authority over some set of names.
But by allowing one special name to stand for the whole domain, this
convention seems like it could violate the intention of the name constraints
extension.

For example, suppose a CA's certificate has the email name constraint
"permitted subtree = acme.com".  This only allows the CA to issue
certificates for mailbox addresses at the host acme.com, not for all
addresses within the acme.com domain.  But if the CA issues a certificate to
domain-signing-authority(_at_)acme(_dot_)com, this domain signing authority 
will be
trusted to sign for, say, bob(_at_)marketing(_dot_)acme(_dot_)com(_dot_)  It 
seems odd that the CA
could grant a domain signing authority the ability to sign for Bob, since
the CA was not itself trusted to issue Bob a certificate.    

So perhaps it would be better to allow domain authority certificates to use
the name constraints extension, instead of a specialized naming convention,
to express who they are authoritative for, and to extend validation of CA
name constraints to the domain authority certificate.  Then the above
violation of name constraints couldn't occur, and RFC 3183 could be made
simpler, since it could reference a pre-existing mechanism for delimiting
trust, and not have to invent its own.

A further advantage might be that the name constraints extension is more
expressive than the RFC 3183 naming convention, since name constraints can
specify trust on the basis of hosts instead of whole domains, and can
exclude particular hosts, mailboxes, or subdomains, from the granting of
trust as well..

Trevor

<Prev in Thread] Current Thread [Next in Thread>
  • RFC 3183: Domain Security Services, Trevor Perrin <=