OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] Action point on PRocessingDetails and reports


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.



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

Juan Carlos.

>Just a thought, I don't have a definite opinion here yet.
>
>
>Trevor
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]