RE: AC509 Login Name

[Peter Williams <peterw@xxxxxxxxxxxx>]

There are a number of ancillary subject-related
details that one would quite naturally wish
to associate with an identified subject, depending
upon its object type, to make PKIX more useful
to more technical communication processes. Whereas
PKIX has traditionally been focuses on persons
and organizations, this is not the limit
of PKIX applicability. Host, Domains and Routers
are now receiving certs in practice.

You have identified that object class "Account"
needs a naming or other type of subject attribute,
which describes a login name to be associated,
appropriately, with an id- or privilege cert. And you 
seem to be attempting to find a format
and transmission field for such information.

But there other examples of additional
subject information; I suggest the
scope of the question be widened slightly,
so that the PKIX community agreements for 
the login value case are reusable for 
other similar localized situations.

ftp://ftp.isi.edu/in-notes/rfc2714.txt describes
the CORBA object referencing framework in IETF
LDAP directories.  The various interface names and 
references are naturally tied to "Host" objects referred to 
by the names bound to X.509 id-certs. In that Internet deployment
scenario, the Host chooses to export a given set of named
interfaces, and wishes to bind those
formal interface names and/or references to
its id- or privilege cert.  

ftp://ftp.isi.edu/in-notes/rfc2713.txt describes
additional attributes that would need to
be similarly associated with an identified entity.
to ensure java protocol entity references are bound 
to the identified server.

-----Original Message-----
From: Nick Pope [mailto:pope@secstan.com]
Sent: Tuesday, December 21, 1999 9:30 AM
To: stephen.farrell@baltimore.ie
Cc: ietf-pkix@imc.org
Subject: RE: AC509 Login Name


Thanks to Kensaku, Andy and Stephen for all their comments.

I don't think OTHER-NAME on its own meets my requirement.  This requires a
OBJECT (type) IDENTIFIER to be registered so that others can recognise the
type.

I do not want to use rfc822Name as this misuses the field and has the wrong
semantics associated with it.

We could :

a) register a new OTHER-NAME type (as has been done in the QC draft)with its
OBJECT IDENTIFIER
e.g. using ASN.1 93:
flatname OTHER-NAME ::= {
          UTF8String IDENTIFIED BY  id-on-flatname}
id-on-flatname OBJECT IDENTIFIER  ::=  {id-pkix-on ?}

b) use the FlatOrGeneralName syntax given below could be used.

Either of the above would suite me.  The implementor in me likes (b); the
structured designer in me prefers (a).

Nick


> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: 21 December 1999 12:15
> To: Nick Pope
> Cc: ietf-pkix@imc.org
> Subject: Re: AC509 Login Name
>
>
>
> Hi Nick,
>
> > I am working on the use of attribute certificates for secure access to a
> > database, where the user's global identity authenticated using
> SSL/TLS needs
> > to be securely mapped to a local login name.
> >
> > I presume that the Access Identity, as defined in 4.5.2 of
> > <draft-ietf-pkix-ac509prof-01>, can be used for this function.
>
> That's the intent.
>
> > However, I cannot find an existing name form defined in X.509 for
> > GeneralNames which could be used for a local login name.
>
> Bit naughty, but what about using rfc822Name? It does map reasonably
> well in lots of cases so long as IA5String isn't a problem.
>
> > Could one be defined as part of the IETF attribute certificate profile?
> >
> > What syntax should this take?  A choice between UTF-8 and
> General Name would
> > be the simplest.
>
> So you mean you'd prefer something like:
>
>         SvceAuthInfo ::=    SEQUENCE {
>                 service   FlatOrGeneralName,
>                 ident     FlatOrGeneralName,
>                 authInfo  OCTET STRING OPTIONAL
>         }
>
>         FlatOrGeneralName ::= CHOICE {
>                 flat    UTF8String,
>                 gen     GeneralName
> 	}
>
> I wouldn't have a problem with this, if you're sure you can't
> use the rfc822 field (and I think I prefer the above to the use of
> otherName that Andy suggested). Anyone else?
>
> Regards,
> Stephen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 647 7406
> 61 Fitzwilliam Lane,                    fax: +353 1 647 7499
> Dublin 2.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
>