Subject: Comments on draft-ietf-pkix-ac509prof-03

From: "Linn, John" <[email-masked]>
Date: Mon, 15 May 2000 16:44:42 -0400

I'd like to offer some Last-Call comments and questions on
draft-ietf-pkix-ac509prof-03.txt. 

Specifics:

In Section 4.2, 1st paragraph, [PKINIT]'s CAT-WG Last-Call is currently
pending on revisions to another document; it hasn't yet been submitted to
the IESG.  Note that if AC509 reaches the RFC editor first, it may find its
progress serialized on a normative reference. 

4.2.6, 2nd line: suggest changing "period for which the AC issuer expects"
to "period for which the AC issuer certifies". It's quite probable that
bindings to attributes will remain valid (and, hence, recertified) across
the lifetimes of many successive short-lived ACs, and that the AC issuer
will have no reason to expect otherwise at the point when an AC is issued.
If a change occurs within an AC's validity period, then revocation can be
applied if available; if not, the attributes' certification remains
inextricably valid until the validity period expires. 

4.3.4, 1st paragraph: new-part1-01 allows a SEQUENCE OF AccessDescription in
an AIA extension, which allows multiple access modes to be specified for
revocation information and/or allows other CA-related information to be
defined and accessed via AIA.  Why apply a tighter constraint (single
AccessDescription only) for use of AIA in ACs?

4.4.1 and 4.4.2: I'm confused about the relationship between Service
Authentication Information and Access Identity attributes.  Both are based
on the SvceAuthInfo structure, differing only in that Access Identity
prohibits inclusion of its authInfo element.   If I'm presenting only a
"service" and an "ident", is there any rationale for deciding whether to do
so in a Service Authentication Information (omitting the OPTIONAL authInfo)
or to do so in an Access Identity? As a verifier, should I look equivalently
at both? Is it valid to present both Service Authentication Information and
Access Identity in a single AC and, if so, are their corresponding elements
expected to match?

4.4.5: Reconsidering the list exchange about prohibiting roleAuthority
because of its X.509 association with role specification certificates, its
prohibition apparently implies that the authority responsible for a role
assignment must always be the AC issuer itself.  This seems to conflict with
requirement 4 under Attribute Types in Section 3.  Do we have a rationale
for requiring authority qualification more strongly for groups than for
roles, or if not do we need another means to represent roles' associated
authorities?

Sec. 5, first numbered list, item 6: I believe that this profile shouldn't
preclude acceptance of ACs bearing critical extensions which are recognized
by the verifier even if those extensions are defined in other documents. 

Sec. 6, penultimate paragraph: I can see why noRevAvail wouldn't coexist
with other revocation-related extensions, but what's the rationale for
diverging from new-part1-01 and prohibiting use of multiple revocation
facilities for an AC?  

Editorial:

4.3.4, 5th paragraph, last line: "administrator identify" -> "administrator
to identify". 

7.1, 5th para, 3rd line: "attribue" -> "attribute". 

Sec. 8, 6th para: "issued to the AC issuer" -> "issued by the AC issuer"?

Sec. 8, 2nd para, 3rd line: "issuer's" -> "issuers".

Sec. 8, penultimate para, penultimate line: "AC verified trusts" -> "AC
verifier trusts". 

--jl

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 May 2000 12:11:41 +0100

Hi John,

> progress serialized on a normative reference.

Do you think we should wait on PKINIT or duplicate the definition
of how to include a KerberosName into a GeneralName? The downside
of the latter is that two specs. define the same OID (krb5PrincipalName),
which is ok so long as the OID doesn't change, but I'd rather refer
to PKINIT so long as it won't cause a v. long hold. What's the likely
downside of waiting on PKINIT? (i.e. what's it depend on, any idea
of likely timing)

> to "period for which the AC issuer certifies". 

Fine.

> AccessDescription only) for use of AIA in ACs?

I guess that was me trying to make the implementation easier, but I've
no problem changing this if folks need more than one. What do others 
think?

> at both? 

The intent is really that svceAuthInfo is usable to authenticate the
AC holder to some application "behind" the AC verifier, whereas, 
accessIdentity is intended to be used for authorization purposes,
"by" the application that includes the AC verifier.

You're right that there is some potential for confusion here. Would
the following additional text help?

In 4.4.1 (svceAuthInfo):

"This attribute is intended to be used to provide 
information, that can be used by the AC verifier (or a 
larger system of which the AC veriifer is a component) 
to authenticate the AC holder to another application.
Note that this is a different use to that intended for
the accessIdentity attribute in 4.4.2 below."

In 4.4.1 (accessIdentity):

"This attribute is intended to be used to provide
information about the AC holder, that can be used
by the AC verifier (or a larger system of which the 
AC veriifer is a component) to authorize the actions 
of the AC holder within the AC verifier's system. Note 
that this is a different use to that intended for 
the svceAuthInfo attribute described in 4.4.1 above."

> Is it valid to present both Service Authentication Information and

It is valid to hold an AC containing both attributes, and of course, each
may be multivalued, so there is no implication of any matching between
the values, even if the service field has the same value. Its really
up to the AC verifier to handle this (and the AC issuer not to issue
nonsense ACs!).

> roles, or if not do we need another means to represent roles' associated

You're right about this, I guess its a side-effect of using
the X.509 role attribute that slipped in:-(

Possible fixes are:

1. add back the role attribute with IetfAttrSyntax and delete 
   the role with RoleSyntax
2. add back the role attribute with IetfAttrSyntax and leave in
   the role with RoleSyntax, and say that if you want 
   policyAuthority information use the one with IetfAttrSyntax
3. use the RoleSyntax.roleAuthority field in a way that doesn't
   fit with X.509 
4. define a method for including the policyAuthority in a http
   URL in the RoleSyntax.roleName field, e.g. 
   "http://[[<host>][:<port>]]/<role>[?pa=<policy-authority>]"
   and recommend that a (human readable) description of the
   role be made available at that URL if a host:port are
   present.
5. Like 3, but define a new uri scheme, e.g. 
   "pkixrole:///<role>[/<policy-authority>]

I'd go for 4, anyone else?

> by the verifier even if those extensions are defined in other documents.

Fine.
 
> diverging from new-part1-01 and prohibiting use of multiple revocation

I guess my response is the same as to your comment on 4.3.4: simplicity
for the implementor, and as above, I'm ok with changing it if folks want
that.

BTW: As an aside, is the relying party behaviour when faced with a 
cert (PKC or AC) containing many sources of revocation status well 
defined? 

> Sec. 8, penultimate para, penultimate line: "AC verified trusts" -> "AC

Ta,
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: "Andy Dowling" <[email-masked]>
Date: Tue, 16 May 2000 13:16:15 +0100

Hi all,

> I'd go for 4, anyone else?

If we do go for either 4 or 5, we'll need a standardised and "human
readable"
form of GeneralNames (which is what IETFAttrSyntax uses for the P.A.) in
order
to achieve the same level of flexibility with regard to naming a P.A.

For example, let's suppose that we restrict our P.A. to a *single*
GeneralName
for encoding simplicity:

The PA could be represented in the URL using the string representation
of GeneralName from the PKIX group:

http://manager?pa=directory: C=IE, O=SSE, CN=PA1   (Option 4)
pkixrole://manager/directory: C=IE, O=SSE, CN=PA1   (Option 5)

One question here would be how to handle spacing, etc.
Will we permit spaces in this, or would we have to use the %HEX encoding
scheme used on the web. If we do have to decode the hexes, this seems like
a lot of overhead for decoding a simple PA GeneralNames. :-(

Given such an encoding/decoding overhead, I'd be more inclined to go for 2.

Any comments, folks?

Andy