Subject: Trusted root names

From: Jonathan Wood <[email-masked]>
Date: Tue, 14 Oct 2003 20:15:20 -0700

I'm not sure that using a FQDN (i.e. hostname) to represent
a trusted root is a good thing, since intermediate and root
authorities might not be hosts. Also, if we want to use FQDNs
in SEND in this fasion, won't we need to also mandate a
certificate profile that requires the inclusion of DNS alt subj
names in each cert?

I would rather that we stuck with using the basic subject field
in a cert. If we do, we would need some changes in the trusted
root option: the name should probably be DER-encoded X501
Name type (which is how it is encoded in a cert), and we
would not need the pad length any more, since the DER-encoding
would give us that information. Section 6.6 would also need
to change references to subjectAltName.

Comments?

Jonathan

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 15 Oct 2003 09:35:16 +0300

> to change references to subjectAltName.

We discussed this issue at the DT for some length, but I don't
remember any more all of the details.  In any case, I would
have liked to use a hash of the root public key to represent
the root, but that was not considered as a good choice since
it would be fairly hard to use such a hash as a search key.

I think it was mostly James who prefererred the FQDN, and
if I remember right, the main reason was the ease of using
it as a search key.  That is, if we use the FQDN to represent
the root, we can use either LDAP or DNS to store the keys
and to retrieve them.

Anyway, for me it is OK to define a new type of the name
field, as an alternativity to the FQDN, both being equally
acceptable (and both being mandatory to implement).
Here is the suggestion:

     When the Name Type field is set to 2, the Name field
     contains a DER encoded X.501 certificate Name, represented
     and encoded exactly as in the matching X.509v3 root
     certificate.

What comes to Section 6.6, you are right.  It needs to be
revised so that the FQDN is not really mentioned, but the
text should be more generic.  Here is my suggestion,
presuming that we define a DER encoded subject format.

Old text:

   In a solicited-for advertisement, the router SHOULD include
   suitable Certificate options so that a delegation chain to the
   solicited root can be established.  The root is identified by
   the FQDN from the Trusted Root option being equal to an FQDN
   in the subjectAltName field of the root's certificate. The
   router SHOULD include the Trusted Root option(s) in the
   advertisement for which the delegation chain was found.

New text:

   In a solicited-for advertisement, the router SHOULD include
   suitable Certificate options so that a delegation chain to the
   solicited root can be established.  The root is identified by
   the Trusted Root option.  If the Trusted Root option is
   represented as an FQDN, the FQDN must be equal to an FQDN in
   the subjectAltName field of the root's certificate.  If the
   Trusted Root option is represented as a DER Encoded X.501
   Name, then the Name must be equal to the Subject field in the
   root's certificate.  The router SHOULD include the Trusted
   Root option(s) in the advertisement for which the delegation
   chain was found.

Ok?

--Pekka Nikander

---

From: "James Kempf" <[email-masked]>
Date: Wed, 15 Oct 2003 10:24:13 -0700

Pekka,

I don't have any problem with using a DN for this. From talking with some
people about it, it seems as if a DN is used for SSL as well, so this seems
to be standard practice. Also, from a simplicity standpoint, I think it
makes sense to minimize the diffs between this and the PKIX IP Address
extension, to avoid implementation and deployment complexity.

As for obtaining a key in the DNS, I recall we did discuss this in the DT,
but given the current design, I am not sure whether there is any benefit in
adding an additional field to the certificate for that purpose if it
requires the network operator to modify how they would utilize the standard
PKIX router certs. The assumed use case here is that the host has the cert
chain for the trusted root preloaded rather than opportunistically being
able to get the key from the DNS. I think this use case is likely for the
near future.

So, I'd suggest that rather than having both the DN and FQDN be required to
implement, the former be required and the latter be optional. This would
simplify the most likely current deployment base design. When SEND goes from
PS to DS, the design can be re-examined based on deployment experience.

How does that sound?

            jak

---

From: Jonathan Wood <[email-masked]>
Date: Wed, 15 Oct 2003 11:39:40 -0700

On Tuesday, October 14, 2003, at 11:35 PM, Pekka Nikander wrote:

<...>

>   Root option(s) in the advertisement for which the delegation

This is better. However I'm now concerned that this may cause
interop issues, in that unless the rest of the PKI infrastructure
is set up to handle each case, nodes may not be able to find
delegation chains. For example, if a node sends a DCS with
a DNS name trust anchor option, and either the PKI supports
only lookups by DNs or the trust anchor certificate doesn't have
a DNS alt name extension, then no routers will be able to
provide a DC for the requested trust anchor (even though one
might exist if indexed by the DN).

I guess my discomfort with the DNS alt name stems primarily
from my concern that DNS alt names may not always be there in
certs and lookup tables, whereas I feel it more likely that DNs will
be there. However, I am no PKI expert, so I will happily yield
to a counter argument based on more solid information :)

Jonathan

---

From: "James Kempf" <[email-masked]>
Date: Wed, 15 Oct 2003 16:04:36 -0700

Hi Jon,

> to a counter argument based on more solid information :)

Well, I suppose I agree on this. Even having the DNS alt name in as an
option has the potential to lead to additional implementation and deployment
complexity. Keeping SEND simple is more likely to cause people to want to
implement it (a viewpoint from Randy Bush that I am beginning to
appreciate).

Perhaps the best course, for now, would be to simply require the DN and
leave any mention of the DNS alt name out. If DNS keys become widely
deployed, the spec can be revised at that time to include it as an
alternative.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 16 Oct 2003 09:54:42 +0200

>>> solicited root can be established.  The root is identified by the
>>> Trusted Root option.  If the Trusted Root option is represented
>>> as an FQDN, the FQDN must be equal to an FQDN in the
>>> subjectAltName field of the root's certificate.  If the Trusted
>>> Root option is represented as a DER Encoded X.501 Name, then the
>>> Name must be equal to the Subject field in the root's
>>> certificate.  The router SHOULD include the Trusted Root
>>> option(s) in the advertisement for which the delegation chain was
>>> found.
>> 
>> interop issues, ...
>> I guess my discomfort with the DNS alt name stems primarily from my
>> concern that DNS alt names may not always be there in certs and
>> lookup tables, whereas I feel it more likely that DNs will be
>> there. ...
> 
> Well, I suppose I agree on this. Even having the DNS alt name in as
> an option has the potential to lead to additional implementation and
> deployment complexity.  Keeping SEND simple is more likely to cause
> people to want to implement it (a viewpoint from Randy Bush that I am
> beginning to appreciate).

Having the FQDN there as an OPTIONAL feature doesn't add much
implementation complexity.  The deployment complexity may be
a real issue, though.

> Perhaps the best course, for now, would be to simply require the DN
> and leave any mention of the DNS alt name out. If DNS keys become
> widely deployed, the spec can be revised at that time to include it
> as an alternative.

Well, for the current version of the draft, I did the following:

  - reordered the names so that DER Encoded X.501 Name is number 1
    and FQDN is number 2

  - made FQDN support OPTIONAL

  - added a requirement that a each Delegation Chain Solitiation
    MUST have at the first (or only) Trust Anchor option a DER
    Encoded X.501 Name.

I think that this is more future proof, taking even care of
the situation where people are using new types of Trust Anchors.

What do you think?

--Pekka

---

From: Jonathan Wood <[email-masked]>
Date: Thu, 16 Oct 2003 11:48:54 -0700

> the situation where people are using new types of Trust Anchors.

I am happy with this.

Jonathan

---

From: "James Kempf" <[email-masked]>
Date: Thu, 16 Oct 2003 11:52:48 -0700

Fine by me as well.

            jak

----- Original Message ----- 
From: "Jonathan Wood" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "SEND WG"
<[email-masked]>
Sent: Thursday, October 16, 2003 11:48 AM
Subject: Re: Trusted root names