headers
Steve Hanna | 2 Nov 2000 15:50
Picon

Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

We now have 11 possible formats for the Holder field:

1) baseCertificateID only
2) entityName only
3) baseCertificateID and entityName
4) objectDigestInfo only with publicKey hash
5) objectDigestInfo only with publicKeyCert hash
6) baseCertificateID and objectDigestInfo with publicKey hash
7) baseCertificateID and objectDigestInfo with publicKeyCert hash
8) entityName and objectDigestInfo with publicKey hash
9) entityName and objectDigestInfo with publicKeyCert hash
10) baseCertificateID, entityName, and objectDigestInfo with publicKey
    hash
11) baseCertificateID, entityName, and objectDigestInfo with
    publicKeyCert hash

Given that we're designing a *profile* of X.509 ACs, can we choose one
or two of these formats, recommend that AC issuers only use those, and
require that AC verifiers be able to process them? If not, then I'm
afraid interoperability will be impossible.

Let's see if I can narrow things down a bit. I'll start by pointing out
that using objectDigestInfo with publicKeyCert hash may cause problems
if the holder wants to use a different PKC to authenticate than the one
whose hash is in the AC. Using objectDigestInfo with publicKey hash
should resolve the concern raised by Polar (problems with inconsistent
or duplicative naming). So I suggest that we not recommend the use of
formats 5, 7, 9, and 11 above.

Is there any reason *not* to include a publicKey hash in the Holder?
(Continue reading)

Permalink | Reply | 9 comments |
headers
Polar Humenn | 2 Nov 2000 17:58

Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)


Hi Steve,
Comments below.

On Thu, 2 Nov 2000, Steve Hanna wrote:

> We now have 11 possible formats for the Holder field:
> 
> 1) baseCertificateID only
> 2) entityName only
> 3) baseCertificateID and entityName
> 4) objectDigestInfo only with publicKey hash
> 5) objectDigestInfo only with publicKeyCert hash
> 6) baseCertificateID and objectDigestInfo with publicKey hash
> 7) baseCertificateID and objectDigestInfo with publicKeyCert hash
> 8) entityName and objectDigestInfo with publicKey hash
> 9) entityName and objectDigestInfo with publicKeyCert hash
> 10) baseCertificateID, entityName, and objectDigestInfo with publicKey
>     hash
> 11) baseCertificateID, entityName, and objectDigestInfo with
>     publicKeyCert hash
> 
> Given that we're designing a *profile* of X.509 ACs, can we choose one
> or two of these formats, recommend that AC issuers only use those, and
> require that AC verifiers be able to process them? If not, then I'm
> afraid interoperability will be impossible.

I don't see why not following X.509 isn't a good thing. And why would
interoperability be impossible?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jeffrey I. Schiller | 2 Nov 2000 18:00
Picon
Favicon

QC Document just passed the IESG


The Qualified Certificates document <draft-ietf-pkix-qc-06.txt> just
passed during the IESG teleconference (within the last 5 minutes).

                       -Jeff
Permalink | Reply | 0 comments |
headers
Tom Gindin/Watson/IBM | 2 Nov 2000 18:21
Picon
Favicon

Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)


     My own recommendations would run almost opposite yours.  In the
extreme case, option 7 is clearly preferable to option 6 because both
options specify a specific certificate (as does option 1), and option 7
locks down the whole certificate while option 6 does not.  It is also
clearly preferable to option 5, which specifies a single certificate
without making it locatable.  A similar argument prefers option 11 to
option 10 and option 3.  So now we have reasons IMO to prefer 7 or 11 to 1,
3, 5, 6 or 10.
     This leaves 2, 4, 8, and 9.  Case 2 is of independent value and should
be permitted.  Case 4 is somewhat debatable - its meaning is "I'll accept
any unrevoked and unexpired certificate with this particular key" and case
8 is more secure, but case 4 permits a name change while 8 doesn't.  Case 9
is a simplified case of 11 (as 7 also is) and is not particularly
necessary.

     So I would recommend that RP's MUST support cases 2 and 11, SHOULD
support cases 7 and 9, and I'd poll the group on whether 4 is better than 8
or not.

          Tom Gindin

Steve Hanna <steve.hanna <at> sun.com> on 11/02/2000 09:50:45 AM

To:   "David P. Kemp" <dpkemp <at> missi.ncsc.mil>
cc:   ietf-pkix <at> imc.org
Subject:  Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

We now have 11 possible formats for the Holder field:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeffrey I. Schiller | 2 Nov 2000 18:23
Picon
Favicon

draft-ietf-pkix-dcs-07.txt approved for an EXPERIMENTAL Document


The IESG has agreed to public Certification Server Protocols
<draft-ietf-pkix-dcs-07.txt> as an EXPERIMENTAL RFC.

The RFC Editor will be instructed to add the text:

  "The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF
   Executive Director."

to the document. I am not sure where it will be added, I suspect
either near the beginning or in Section 12 (Patents).

                      -Jeff
Permalink | Reply | 0 comments |
headers
Steve Hanna | 2 Nov 2000 18:57
Picon

Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

Polar Humenn wrote:
> On Thu, 2 Nov 2000, Steve Hanna wrote:
> > We now have 11 possible formats for the Holder field:
> >
> > 1) baseCertificateID only
> > 2) entityName only
> > 3) baseCertificateID and entityName
> > 4) objectDigestInfo only with publicKey hash
> > 5) objectDigestInfo only with publicKeyCert hash
> > 6) baseCertificateID and objectDigestInfo with publicKey hash
> > 7) baseCertificateID and objectDigestInfo with publicKeyCert hash
> > 8) entityName and objectDigestInfo with publicKey hash
> > 9) entityName and objectDigestInfo with publicKeyCert hash
> > 10) baseCertificateID, entityName, and objectDigestInfo with publicKey
> >     hash
> > 11) baseCertificateID, entityName, and objectDigestInfo with
> >     publicKeyCert hash
> >
> > Given that we're designing a *profile* of X.509 ACs, can we choose one
> > or two of these formats, recommend that AC issuers only use those, and
> > require that AC verifiers be able to process them? If not, then I'm
> > afraid interoperability will be impossible.
> 
> I don't see why not following X.509 isn't a good thing. And why would
> interoperability be impossible?

The goal of the ac509prof draft is to define a profile of X.509
attribute certificates for use with Internet protocols. As such, it is
to be expected that we will make recommendations about which features
SHOULD or MUST be supported.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Steve Hanna | 2 Nov 2000 19:02
Picon

Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

Tom Gindin/Watson/IBM wrote:
> 
>      My own recommendations would run almost opposite yours.  In the
> extreme case, option 7 is clearly preferable to option 6 because both
> options specify a specific certificate (as does option 1), and option 7
> locks down the whole certificate while option 6 does not.

You assume that baseCertificateID specifies a particular PKC. When used
in combination with objectDigestInfo, it does not. It only specifies a
searching hint (as Sharon said). Other PKCs that meet the requirements
of the objectDigestInfo will suffice. So option 6 would work with any
PKC that has the specified public key. If this is desirable, option 6 is
superior to option 7. I see little argument for option 1 over option 7,
however. It specifies a particular PKC without the extra protection of a
hash.

> It is also
> clearly preferable to option 5, which specifies a single certificate
> without making it locatable.

Agreed. Option 5 is not very useful.

> A similar argument prefers option 11 to
> option 10 and option 3.

As described above, I don't agree that option 11 is necessarily superior
to option 10. However, I do agree that option 11 is superior to option
3.

So now we have reasons IMO to prefer 7 or 11 to 1,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Polar Humenn | 2 Nov 2000 20:00

Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)


Hi Steve!

On Thu, 2 Nov 2000, Steve Hanna wrote:

<snip>

> The goal of the ac509prof draft is to define a profile of X.509
> attribute certificates for use with Internet protocols. 

Below you asked me for specific examples. So, can you please give me an a
definite list of which Internet protocols are supposed to support this
attribute certificate?

> As such, it is to be expected that we will make recommendations about
> which features SHOULD or MUST be supported.
> 
> It's unlikely that most implementors will want to support all 11 formats
> listed above. If we can identify one or two formats that are sufficient
> for use with Internet protocols and recommend that those formats be
> supported, then we can increase the chances of successful
> interoperation. If we make no such recommendations, it's unlikely that
> we can achieve this.

I understand that. But different applications and different protocols need
different things.

> > > Let's see if I can narrow things down a bit. I'll start by pointing out
> > > that using objectDigestInfo with publicKeyCert hash may cause problems
> > > if the holder wants to use a different PKC to authenticate than the one
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jean-Marc Desperrier | 2 Nov 2000 20:23

Extended Key Usage and path validation

I've been trying recently to understand how path validation should be
done for the usage of a key.

Until now, the only document that I've found that's really explicit is
the following from Netscape/iPlanet :
http://docs.iplanet.com/docs/manuals/cms/41/dep_gide/ext.htm

Netscape, in this document, says this about extended key usage in path
validation.

"A given certificate is valid only for the intersection of key usages of
all the certificates in the chain to its root (as determined by both the

Extended Key Usage extension for each certificate and the corresponding
user settings). To be valid for a particular usage, the end-entity
certificate and all certificates in the chain must all be valid for that
usage"

In fact, in the context it's not very clear whether this is what
Netscape recommends or the current practice of Microsoft softwares.

But their recommendation for certificat format in table B.1 of that
document is perfectly coherent with that.

This path validation does not apply to keyUsage.
A CA with a keyUsage of keyCertSign, cRLSign, can perfectly emit a valid
certificate with a keyUsage of digitalSignature.

I've been reading through RFC2459, and I was not able able to find
anything that really supports this behaviour.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Hanna | 2 Nov 2000 20:50
Picon

Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

Polar Humenn wrote:
> On Thu, 2 Nov 2000, Steve Hanna wrote:
> > The goal of the ac509prof draft is to define a profile of X.509
> > attribute certificates for use with Internet protocols.
> 
> Below you asked me for specific examples. So, can you please give me an a
> definite list of which Internet protocols are supposed to support this
> attribute certificate?

ac509prof says "The profile places emphasis on attribute certificate
support for Internet electronic mail, IPsec, and WWW security
applications." So I expect that S/MIME, IPsec, and TLS would be the most
important protocols for this profile.

> > As such, it is to be expected that we will make recommendations about
> > which features SHOULD or MUST be supported.
> >
> > It's unlikely that most implementors will want to support all 11 formats
> > listed above. If we can identify one or two formats that are sufficient
> > for use with Internet protocols and recommend that those formats be
> > supported, then we can increase the chances of successful
> > interoperation. If we make no such recommendations, it's unlikely that
> > we can achieve this.
> 
> I understand that. But different applications and different protocols need
> different things.

Sure. If you can identify an important reason why one of these formats
is needed for the protocols of concern to us, then we should keep it.
Otherwise, we should not.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane