Subject: AC509 Login Name

From: "Nick Pope" <[email-masked]>
Date: Mon, 20 Dec 1999 17:59:29 -0000

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.

However, I cannot find an existing name form defined in X.509 for
GeneralNames which could be used for a local login name.

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.

Nick Pope

---

From: "Andy Dowling" <[email-masked]>
Date: Tue, 21 Dec 1999 09:16:07 -0000

Nick,

I don't see the need to define any new name form.
Why not simply use the "otherName" (OCTET STRING) choice of GeneralName,
and encode the DER-encoded UTF8String (or whatever) inside that?
(i.e. just like AC/PKC extensions do it). The profile specifies that
otherName must not
be used as a GeneralName choice unless otherwise specified, but I'm sure an
exception
can be made in this case - eh Stephen? :-)

Regards,

Andy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Dec 1999 12:15:15 +0000

Hi Nick,

> <draft-ietf-pkix-ac509prof-01>, can be used for this function.

That's the intent.

> 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.

> What syntax should this take?  A choice between UTF-8 and General Name would

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:[email-masked]
Ireland                             http://www.baltimore.com

---

From: [email-masked] (Kensaku Masuda)
Date: Tue, 21 Dec 1999 21:41:20 +0900 (JST)

Hi everyybody.

<[email-masked]>の記事において
[email-masked]。

>> to be securely mapped to a local login name.

We going to implement ac's CA. And discus about same problem.

>well in lots of cases so long as IA5String isn't a problem.

It's same result of our implement. Because We need items that are
hostname and user name.
It is simplest choice for us.

---
Fingerprint16 = 4F CC 44 F8 54 BE 45 3A  4F 9F 1C 4E 5E 3B 91 E9
Fingerprint20 = 12CA 6B2D DC50 8248 A636  992B 0292 F548 D65F 4D5B
-----------------+-----------------------------------増田　健作---+
三・六を守ろう！ | [email-masked]                            |
　お家へ帰ろう！ |   [email-masked]                    |
                 |     http://www.st.rim.or.jp/~greg/             |
-----------------+------------------------------------------------+

---

From: "Nick Pope" <[email-masked]>
Date: Tue, 21 Dec 1999 17:30:18 -0000

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:[email-masked]]
> Sent: 21 December 1999 12:15
> To: Nick Pope
> Cc: [email-masked]
> Subject: Re: AC509 Login Name
>
>
>
> Hi Nick,
>