Subject: Attribute Certificates II

From: Pedro Miguel Pereira Borges <[email-masked]>
Date: Wed, 18 Oct 2000 16:45:06 +0200

Hi all :)

   I'm interested in Attribute Certificates and I tried to keep up with
the latest thread but since it was 37 mails long, at some point I was
lost...
   So sorry if this is a re-run :)
   Even so, after reading the latest version, I have some questions that
I hope you can make clearer for me :) :

        -> In section 4.2.3 it's said that all AC Issuers must be
identified by non-empty DNs. It's also said that "it means that the AC
Issuer does not have to know which PKC the verifier will use for it (the
AC Issuer). Using the baseCertificateID field to reference the AC Issuer
would mean that the AC verifier would have to trust the PKC that the AC
Issuer chosed (for itself) at the AC creation time.".
         
           If that is so, then how does the relying party know what AC
Issuer PKC it should use to verify the signature on the AC ?

        -> If the holder is identified using the "entityName" field can
you assure that only the authentic holder can gain access to some
resource and not another party (with an equal DN) ?
          As far as I know, presenting the AC isn't enough... You also
have to present a proof of possesion (usually the signature of a
challenge) of something that only that identity knows (like the private
key corresponding to the cert's public key)...
           Am I wrong ?
           Or, when you use this field, who presents the AC gets the
access and that's it ?

        -> Regarding the previous point, if you use the
"objectDigestInfo" of a public key or cert, you could make that proof of
possesion right ?

        -> Are supposing that it's the job of a lower software
layer/protocol to verify/ensure that the AC is being presented by the
righteous owner ?
          If so, do you have any protocol in mind ?

   Thanks in advance,

        Pedro Borges   

-----------------------------------------------------------------------
Pedro Miguel Pereira Borges                            <[email-masked]>
SIBS - Sociedade Interbancária de Serviços, S.A.  <http://www.sibs.pt/>
Rua Soeiro Pereira Gomes, Lote 1 - 1649-031 Lisboa, Portugal
Tel: + 351 21 791 88 00                         Fax: + 351 21 794 24 40
Certificate Fingerprint 20:A2:77:C5:15:5E:D7:A2:DF:D5:27:53:4A:99:94:37
-----------------------------------------------------------------------
This message was signed with a certificate issued by MULTICERT SIBS.
To validate the signature you must obtain the 'MULTICERT Pilot'
Certification Authority certificate, at http://www.sibs.multicert.com/
-----------------------------------------------------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2000 03:10:42 +0100

Pedro,

> Issuer PKC it should use to verify the signature on the AC ?

This is entirely analagous to verifying the signature on a PKC, even
down to the ability to include an AKID in the AC. Just the same, no
different.

>            Or, when you use this field, who presents the AC gets the

No, that isn't it. Protocols using this profile would have to specify how 
theft of ACs is prevented. The security considerations section describes
some of the issues and the proposed additional text adds some more.

Incidentally, what you call proof-of-possession above I would call
authentication.

> "objectDigestInfo" of a public key or cert, you could make that proof of

Indirectly. If the authentication is based on the relevant public key or
PKC.

>           If so, do you have any protocol in mind ?

I don't understand the question. In any case, since this is just
a profile, such protocol issues are out of scope.

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