Re: Comments on best practices revision

Pratik Datta wrote:
> Just be clear, both of us are saying that the Retrieval Method points to 
> the the child of a KeyInfo, and not the KeyInfo itself, isn't it?

Currently, yes. We're in agreement on that issue (meaning we both think 
there's a problem), I think.

> Maybe I am not understanding "PKIX processing".  An <X509Data> can have
> multiple X509 certificates that are part of a certificate chain, so a 
> signature implementation needs to string them together and check it 
> against the established trust points, and then probably check against 
> CRLs or OCSPs, does it not?

That is a specific technical approach that can be replaced by others. A 
sender may well include a certificate chain precisely because it does not 
know exactly how the relying party plans to establish trust, and so it 
doesn't know what it can omit.

There's nothing in the signature specs that in any way mandates that a 
relying party has to do anything when it receives an X.509 certificate 
inside a signature other than "determine that the signing key is trusted". 
It's perfectly legal, in an environment based on key exchange through other 
methods, to use the certificate in the signature as nothing other than a 
container for a key, and determine that the key is trusted in a way that has 
nothing whatsoever to do with the certificate.

I am just asking that we preserve that flexibility and not create any 
"hidden" mandates for using a full PKI in response to a signature that 
happens to contain a certificate.

> I agree that this should be handed over to a 
> different library, and not done by the XML Signature processing library, 
> but XML signature processing library would need to parse this X509Data 
> elements and create a certficate chain and then hand it over to a 
> CertPathValidtor library.

It needs to hand it over, but to what isn't specified. Determining what 
"trust" means is up to the code that it hands it to, and that doesn't have 
to be a PKIX library (or anything X.509-based at all).

> It would be great if you can rephrase and 
> expand on this section, and suggest the other approaches that you were 
> mentioning.  We have a lot of experts in this working group, and I would 
> like to see the Best Practices grow to include everybody's experience in 
> xml signatures, rather than shrink to be technically accurate.

I'm certainly willing to do that if my suggestion to simply remove or weaken 
the existing text is not sufficient. In effect, I'm really just suggesting 
taking the existing text and wrapping it in language like "For example, one 
may....". Maybe with the addition of a sentence like "Other, equivalent, 
means of evaluating the signing key may also be used."

I'll try and take a stab at it.

-- Scott

Received on Wednesday, 3 September 2008 01:28:32 UTC