headers
Nico Williams | 2 Jul 2012 19:23

Re: IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

On Mon, Jul 2, 2012 at 11:46 AM, Stephen Kent <kent <at> bbn.com> wrote:
> Two observations:
>         - one need not use the subject name for access control decisions
>         - one can represent a DNS name as Subject name, using the DC
> attribute

The former would be nice, but since that's not what's implemented,
it's not really possible to issue certificates with meaningless
(unique, effectively pseudonymous) subjectNames.  The latter works for
only one name type, and it's a hack.  But that's the point: being
forced to use the useless Name type means we're forced to encode
better name types as Name using ad-hoc conventions.  x.500-style
naming is stupid and worse than useless -- it is harmful.

Nico
--
Permalink | Reply |
headers
Stephen Kent | 2 Jul 2012 20:14
Picon

Re: IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

At 12:23 PM -0500 7/2/12, Nico Williams wrote:
>On Mon, Jul 2, 2012 at 11:46 AM, Stephen Kent <kent <at> bbn.com> wrote:
>>  Two observations:
>>          - one need not use the subject name for access control decisions
>>          - one can represent a DNS name as Subject name, using the DC
>>  attribute
>
>The former would be nice, but since that's not what's implemented,
>it's not really possible to issue certificates with meaningless
>(unique, effectively pseudonymous) subjectNames.

are you familiar with the RPKI, where the Subject and Issuer names
typically are hashes of public keys? See RFCs 6480-6493.

>   The latter works for
>only one name type, and it's a hack.

it is precisely the name type that you cited as a more natural one.
IP addresses are are supported via Alt names, too.

>   But that's the point: being
>forced to use the useless Name type means we're forced to encode
>better name types as Name using ad-hoc conventions.

I should have mentioned that PKIX does NOT require a Subject name
in an end-entity cert, which is the type of cert relevant to end-point
authentication in these contexts.  So, the only directory name in
such certs would be for the issuer.

>   x.500-style
(Continue reading)

Permalink | Reply |
headers
Stephen Kent | 2 Jul 2012 20:18
Picon

Re: IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

At 12:23 PM -0500 7/2/12, Nico Williams wrote:
>On Mon, Jul 2, 2012 at 11:46 AM, Stephen Kent <kent <at> bbn.com> wrote:
>>  Two observations:
>>          - one need not use the subject name for access control decisions
>>          - one can represent a DNS name as Subject name, using the DC
>>  attribute
>
>The former would be nice, but since that's not what's implemented,

implemented by whom? we have lots of examples of bad code for all sorts of
IET standards. My favorite, recent example is an apparent lack of support for
the name constraints extension in a OS of a major vendor. this failure to
support a mandatory feature that has been part of X.509 & PKIX for over
a decade is causing problems as browser vendors and TAs try to limit some
of the damage that results from the unconstrained browser TA model.

>it's not really possible to issue certificates with meaningless
>(unique, effectively pseudonymous) subjectNames.

not true. see my previous message.

Steve
Permalink | Reply |

Gmane