Subject: Re: AttributeCertificates: Why is the holder DN preferred?

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 12 Oct 2000 23:01:27 +0200

Tom,
I think you addressed  a somewhat bigger issue:
The relationship between Subject DN and SubjectAltName.
I.e. where should the poor RP look for identity information?
Unfortunately PIs and the PKIX-recommended place to put e-mail addresses
makes this even mory fuzzy.

/Anders

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Russ Housley <[email-masked]>; pkix <[email-masked]>
Date: Thursday, October 12, 2000 20:31
Subject: Re: AttributeCertificates: Why is the holder DN preferred?

>     I am not misquoting the draft in any important way.  The third
>paragraph (excluding the note) of section 4.2.2 of your current draft
>begins as follows: "If the holder field uses the entityName option and the
>underlying authentication is based on a PKC, then the entityName MUST be
>the same as the PKC subject field, unless the PKC subject field contains an
>empty distinguished name. If the PKC subject field contains an empty
>distinguished name, then the entityName field MUST be identical to one of
>the values of the PKC subjectAltName field extension."  This forbids the
>use of a value from subjectAltName, whether e-mail or PI, as an entityName
>if the subject DN is present.  The preference for baseCertificateID makes
>the issue somewhat less important, but does not eliminate it.
>     As for PI's (whose draft is -01 rather than -00), I cited them as one
>of two reasonable global identifiers for a user in SubjectAltName.  I
>understand that you would not want to hold up this draft for that one, but
>I'm looking for re-wording of this statement to allow SubjectAltName
>components including e-mail, but excluding IP address, DNS name, and
>probably some others.  It might be appropriate to state that the use of
>"OTHER-NAME components specifying the identity of the subject as an
>individual" may be supported as well.
>
>          Tom Gindin
>
>Stephen Farrell <[email-masked]> on 10/12/2000 05:30:30 AM
>
>Please respond to [email-masked]
>
>To:   Tom Gindin/Watson/IBM@IBMUS
>cc:   Russ Housley <[email-masked]>, pkix <[email-masked]>
>Subject:  Re: AttributeCertificates: Why is the holder DN preferred?
>
>
>
>
>Tom,
>
>I think you're misquoting the draft. basdCertificateID is the SHOULD for
>holder
>when PKCs are used for authentiation. When entityName is used, the text
>tells
>you how it should compare to the subject and/or subjectAltName from the
>PKC. It
>does not say that the PKC must use any particular form of subject naming.
>
>There is no reference to PI since right now that's a -00 draft with who
>know
>what future (bright, I'm sure:-) and the AC profile is in IETF wide last
>call.
>
>Stephen.
>
>[email-masked] wrote:
>>
>>      Russ:
>>
>>      On one subject which is connected to what Polar brought up, I am
>> inclined to think that he is right.  In the AC509Prof draft, section
>4.2.2
>> states that for PKC-based authentication the entityName MUST be the same
>as
>> the PKC subject field unless that field is empty.  Why should it be
>> mandatory to prefer the subject DN to either permanent ID's or e-mail
>> addresses, both of which identify individuals in a globally unique way?
>> Name collisions are more likely in the DN space than in either of the
>other
>> two, except for PI's with a default assignment authority, and PI's of
>that
>> sort should be forbidden as entityName's.  This does not imply that most
>of
>> the options within GeneralName are appropriate as entityName's, as I
>don't
>> think they are.
>>
>>           Tom Gindin
>>
>> Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM
>>
>> To:   Polar Humenn <[email-masked]>
>> cc:   Al Arsenault <[email-masked]>, Stephen Farrell
>>       <[email-masked]>, Patrik Fältström <[email-masked]>,
>>       [email-masked], [email-masked], Thumrongsak Kosiyatrakul
>>       <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
>>       Older <[email-masked]>
>> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
>Targets
>>       andProxies
>>
>> Polar:
>>
>> > > Okay, I think I finally figured out what Polar is getting at here,
>but
>> > > I'm not sure what the fix is.  Let me try to illustrate with an
>> example.
>> > >
>> > > (We'll be picking on Stephen a little bit in this; nothing personal
>> > > intended; apologies for any offense.  :-)
>> > >
>> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
>> > > Technologies, OU=Public CAs, CN=The CA".
>> > > That CA has a self signed certificate with subject and issuer both
>> equal
>> > > to the DN above.
>> > >
>> > > Now, there is an end-user certificate issued under that CA.  The
>issuer
>> > > field of that certificate will be the DN above; the subject field is
>> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
>> > > CN=Stephen".
>> > >
>> > > The serial number field will be something like "4434".
>> > >
>> > > Now, an attribute authority has issued our friend Stephen an AC
>> > > consistent with the proposed profile.  The "Holder" field in that AC
>> can
>> > > be one of three things, according to the proposed profile:
>> > >
>> > >       - it can be the issuer and serial number of the base PKC; that
>is
>> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
>> > >
>> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
>> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
>> > >
>> > >       - it can be an ObjectDigest - for which the I-D does not
>require
>> > > support.
>> >
>> >I think the ObjectDigest is truly the only way to go. However, it still
>> >has problems. The object that is talked about must be able to be
>recalled
>> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
>> >delivered with the Holder's Public Key Certificate.
>> >
>> >I don't believe that requiring the delivery of the Holders certificate
>is
>> >unreasonable. Can something like this be mandated in this profile? I
>don't
>> >see how. I only see that in specific protocols. Or am I wrong?
>>
>> PKCs bind a public key to an identity.
>>
>> ACs bind attributes to an identity.
>>
>> Authentication, which includes validating the PKC certification path and
>> having the remote party perform some operation that involves the private
>> key associated with the identity.  Without authentication of the
>identity,
>> who cares what attributes are associated with it?
>>
>> Russ
>
>--
>____________________________________________________________
>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: Tim Polk <[email-masked]>
Date: Thu, 12 Oct 2000 16:14:57 -0400

FYI,

NIST has just posted a white paper that specifies hashing algorithms 
(SHA-256, SHA-384, and SHA-512) that are intended to provide security 
similar to that of the three AES key sizes. Information can be found at 
<http://www.nist.gov/sha/>.

These algorithms "will be proposed in a draft Federal Information 
Processing Standard (FIPS) in 2001. These algorithms are being made 
available for information purposes prior to the publication of the draft 
FIPS. SHA-256 is a 256-bit hash function that is intended to provide 128 
bits of security against collision attacks, and SHA-512 is a 512-bit hash 
function that is intended to provide 256 bits of security. A 384-bit hash 
may be obtained by truncating the SHA-512 output."

The web site has the NIST contact points.

One side note about AES: http://csrc.nist.gov/csor/algorithms.htm contains 
the object identifiers and ASN.1 type definitions for AES parameters for 
protocols built on ASN.1.  The OIDs for the new hash algorithms will follow 
next week.

Thanks,

Tim Polk