RE: XKMS - AuthorityInfoAccess (AIA) extension

Attached is the updated version of the AIA draft. 

Comments inline...

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Friday, May 02, 2003 6:11 AM
> To: Deacon, Alex
> Cc: www-xkms@w3.org
> Subject: Re: XKMS - AuthorityInfoAccess (AIA) extension
> 
> 
> 
> Alex,
> 
> Sounds like a reasonable idea, (esp if you're willing to take the
> PKIX flak that'll accumulate:-).

BTW, I've been asked by the IETF Security AD (Russ) to submit this draft as
an individual submission instead of a PKIX WG draft due to recent efforts to
wrap up PKIX work.  Although I'm sure there will still be some amount of
PKIX flak to deal with :)   

> 
> Just a couple of initial comments, which could wait until a later
> version if you prefer:

You will notice I didn't add to much to this version...just enough to put a
stake in the ground and submit.  We can expand on the details if necessary
as time goes on...

> 
> - Its not enough to say that the CA includes the location of an
> xkms service - I think you have to say what the CA is asserting 
> that the service will do for the PKIX relying party (given that
> you're operating in PKIX mode!). E.g. you might state that a
> validate request presented with (parts of?) the certificate will
> reflect the revocation status in the same way as would an OCSP
> request. You might want to explicitly state that there're no
> guarantees about locates (or the opposite! maybe you want to 
> say that the CA is commiting to answer for its entire DB at
> that location - both being reasonable). And finally, there's 
> a whole new rathole to avoid about whether xkms registers etc.
> can be sent to that location. Stuff along those lines will 
> be needed anyway, I'd say.

I've punted on this issue and stated that the spec does not mandate which
services the CA will provide.  However I agree that it may make sense to add
text to ensure some minimum interop...especially to aid the relying party
with locate/validate services.  Perhaps something like "Responders that
provide Validate/Locate services SHOULD support KeyName, X509Cert,
X509IssuerAndSerial.")

As for register services, perhaps renewal is the only one that make sense in
this scenario.  
  
> - Security considerations really will have to address the relationship
> (or lack thereof) between the CA root key and the xkms responder key.
> Otherwise DNS poisoning attacks could result in trouble happening
> much more easily than otherwise.

Again, I've punted and simply stated that clients must determine the
trustworthiness of the XKMS responders signature before acting upon any
responses.   Personally I like the OCSP model where the responder key is
delegated from the CA that issued the cert, but its not clear if we want to
tie things down to this model.

> - The reference to XKMS doesn't look right to me. Maybe you
> should check how e.g. the xmlsig rec is referenced from the
> equivalent RFC (I didn't check).

I've updated the reference based on W3C ref in the xmldsig RFC.  Hopefully
this is closer?

Anyway, comments on the above and anything else would be appreciated...

Alex



> 


> Cheers,
> Stephen.
> 
> "Deacon, Alex" wrote:
> > 
> > All,
> > 
> > Attached is the 'one page' internet-draft for the XKMS AIA 
> using an OID
> > assigned from the PKIX ARC.
> > 
> > I plan to post this to the PKIX list next week, so please 
> send any comments
> > and/or feedback you may have by then.
> > 
> > Regards,
> > 
> > Alex
> > 
> > > -----Original Message-----
> > > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > > Sent: Thursday, April 24, 2003 12:47 PM
> > > To: dan ash; Hallam-Baker, Phillip; 'Anders Rundgren'; 
> Hallam-Baker,
> > > Phillip
> > > Cc: www-xkms@w3.org
> > > Subject: RE: XKMS - AuthorityInfoAccess (AIA) extension
> > >
> > >
> > >
> > > Sorr, thought I had done reply to all.
> > >
> > > Alex Deaon is writing a 'one page' RFC to request an OID
> > > point in the IETF
> > > PKIX arc. If we don't get that OID point we can create it in
> > > another arc.
> > >
> > > I spoke to Russ Housley about this (the keeper of the IETF
> > > OID arc for PKIX)
> > > and he is OK with it.
> > >
> > >               Phill
> > >
> > > > -----Original Message-----
> > > > From: dan ash [mailto:dash@68summit.com]
> > > > Sent: Thursday, April 24, 2003 2:34 PM
> > > > To: Hallam-Baker, Phillip; 'Anders Rundgren'; 
> Hallam-Baker, Phillip
> > > > Cc: www-xkms@w3.org
> > > > Subject: RE: XKMS - AuthorityInfoAccess (AIA) extension
> > > >
> > > >
> > > > I remember speaking about this at a face-to-face last
> > > summer.  Nothing
> > > > was actually decided, however, we had discussed using 
> Keyinfo from
> > > > XMLSIG... rather than specifying that such info should be
> > > embeded in a
> > > > certificate.  This still seems to me as the best approach.
> > > >
> > > > daniel ash
> > > >
> > > >
> > > > On Thu, 24 Apr 2003 10:43:31 -0700, "Hallam-Baker, Phillip"
> > > > <pbaker@verisign.com> said:
> > > > >
> > > > > I spoke to Russ Housley about this at RSA.
> > > > >
> > > > > Bascially what is going to happen is Alex Deacon will write
> > > > a one page
> > > > > RFC
> > > > > specifying the OID meaning and Russ will assign the OID.
> > > > >
> > > > >   Phill
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> > > > > > Sent: Thursday, April 24, 2003 2:09 PM
> > > > > > To: Hallam-Baker, Phillip
> > > > > > Cc: www-xkms@w3.org
> > > > > > Subject: XKMS - AuthorityInfoAccess (AIA) extension
> > > > > >
> > > > > >
> > > > > > There seems to be no defined XKMS -
> > > > > > AuthorityInfoAccess (AIA) extension [RFC3280]
> > > > > >
> > > > > > Does this mean that AIA is considered as less useful?
> > > > > >
> > > > > > PKIX's HTTP CertStore which is sort of a subset of 
> XKMS defines
> > > > > > such an extension.
> > > > > >
> > > > > > regards
> > > > > > Anders Rundgren
> > > > > >
> > > > >
> > > > >
> > > > --
> > > >   dan ash
> > > >   danielash@fastmail.fm
> > > >
> > > > --
> > > > http://www.fastmail.fm - Choose from over 50 domains or 
> use your own
> > > >
> > >
> > 
> >   
> --------------------------------------------------------------
> --------------------------------------
> >                                       Name: 
> draft-ietf-pkix-xkms-aia-00.txt
> >    draft-ietf-pkix-xkms-aia-00.txt    Type: Plain Text (text/plain)
> >                                   Encoding: quoted-printable
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
>