Re: XKMS - AuthorityInfoAccess (AIA) extension

Hi Alex,

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

Enjoy! :-)

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

No probs. Be nice if you could cc' this list as you submit
updates - not everyone here (nowadays, including me:-) is
subscribed to pkix or ietf-announce.

>>- Its not enough to say that the CA includes the location of an
>>xkms service 
[...]
> 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...

Yes. However, I think you have to tell a pkix client that implements
the pkix cert checking algorithm how to integrate the call-out to the
xkms service. So, its not just an interop issue, there're semantic
things too that different implementers have to do the same, or else you
break the pkix (though not the xkms) rules.

> As for register services, perhaps renewal is the only one that make sense in
> this scenario.  

Agree. I'd even omit renewals.

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

I'd reckon you'd have to end up doing what ocsp did, so that the
xkms responder's key/certificate doesn't always have to be part
of the pkix client's local trusted config.

Cheers,
Stephen.

Received on Wednesday, 6 August 2003 09:38:58 UTC