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

From: "Linn, John" <[email-masked]>
Date: Tue, 16 May 2000 09:53:23 -0400

Stephen, re:

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

I agree with the merits of citing the definition if feasible, and thereby
avoiding the possibility of future divergence. PKINIT is targeted for WG
Last-Call along with Kerberos-Revisions (aka RFC1510bis).  Depending on
scheduling, this may happen either under the current CAT-WG umbrella or
under the auspices of a new WG being chartered specifically to pursue
Kerberos topics. In either case, I hope to see the pair of documents at the
WG Last-Call level in advance of the Pittsburgh meeting.

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

Thanks.  Particularly for long-lived ACs, it seems to me that the same
rationale (multiple revocation mechanisms) as contemplated for new-part1-01
can apply here as well.  Generally, since usage practice for AC management
is an early emerging area, I'm not sure that we've reached the best point to
make informed restrictive judgments about which of the techniques defined
for PKCs and ACs (in X.509) and PKCs (in new-part1-01) will be best
applicable to ACs for the Internet.  As such, my inclination (here, as with
some other comments) was towards flexibility. 

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

Is the central distinction actually (1) authentication vs. authorization, or
(2) between the inclusion of (2a) information which is intended for
interpretation and validation within the AC verifier vs. (2b) information
which the AC verifier is expected to pass on for interpretation by some
other element at the target system?  It seems more like (2) than (1) to me.
For (2b), the AC is basically acting as a container for the attribute, with
its contents' usage for authentication and/or authorization taking place
outside the scope of target-side AC processing. 

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

What about, "information, that can be presented by the AC verifier to be
interpreted and authenticated by a separate application within the target
system"?  If I'm understanding correctly above, it doesn't seem that the AC
verifier is actually performing the authentication. 

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

OK. 

In the interests of conciseness here, I'll defer discussion of the role
authority question to the separate subthread already opened on it. 

--jl

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 May 2000 15:07:13 +0100

John,

"Linn, John" wrote:
> ...PKINIT...

So, we should keep the current text, but be ready to update the
reference? Good.

> some other comments) was towards flexibility.

Maybe I should ask the opposite questions: does anyone object
to including more than one AIA AccessDescription? Does anyone
object to including both AIA and CRLDP in an AC?

> outside the scope of target-side AC processing.

Fine. I've no problem adding the text below, including your mod to
the scveAuthInfo paragraph.

> authority question to the separate subthread already opened on it.

Yep.

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