[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Action point on PRocessingDetails and reports
At 04:41 PM 12/4/2003 +0100, Juan Carlos Cruellas Ibarz wrote: >Trevor, >Thanks for your answer... see below. > > > > >>They do not allow either, for instance to report problems like "unable to > >>contact a OCSP server", or "unable to retrieve the CRL that has to > >>be checked for validating this certificate in the certpath". > > > >They let you report these problems in a general way. For example, both of > >the above would be reflected as: > > <IndeterminateDetail>RevocationStatus</IndeterminateDetail> > > > >This doesn't tell you exactly what failed, or exactly why it failed. > > > >But it's also easier for client and servers, and, well, specification > >editors :-), since we don't have to enumerate every reason why > >revocation-checking might fail. > > > >Also, it's PKIX-agnostic. It would be nice if things didn't depend on > >specific X.509 technologies like CRLs, OCSP, etc.. Then we could use the > >same structures regardless of the underlying key infrastructure (X.509, > >XKMS, PGP, SPKI, etc...). > > >Well, I would say that it is a question of balance between agnosticism and >usefulness in certain environments... if this is something that somebody >could request (and I remember some previous email in our list in favour >of details of verification process -the question is how deep they have to >be), it would be worth to have it. Here's the email thread - you and Andreas were proponents of this: http://lists.oasis-open.org/archives/dss/200306/msg00035.html > > > >I'm not sure if we want such a detailed mechanism. I doubt many clients > >would be able to make use of such detailed reports. > > > >The proposal I sent was based on specific requirements of the entity >that wanted to have such a feature.... > > >If we do, though, maybe we could combine approaches, and have general > >structures, like the current ones, but also have optional details that give > >specifics? We could perhaps keep something like the current structures, > >but each <ValidDetail>, <IndeterminateDetail>, or <InvalidDetail> could > >also contain a list of your <StatusReasonTypes>. > > > >That could be a good solution....this is what I was thinking that could >come up: some kind of combination.... >Should we then try to work in that direction these week and half left >until the next conf call or would you like to hear more opinions on that? If you wanted to spec out such a combined approach, that might be a good base for further discussion. Also, we could try to get Andreas's opinion. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]