Thanks for the proposal Thomas.
This proposal requiring Basic Path Validation seems to conflict with
X509Data being optional, the current language that I think we
discussed during the meeting:
Generation:
5c) The ds:KeyInfo element MAY be included and MAY include
certificate, CRL and/or OCSP information. If so, it MUST be compliant
with the[XMLDSIG11] specification. If certificates are used they MUST
conform to the mandatory certificate format.
Validation:
If a ds:KeyInfo element is present then it MUST conform to the
[XMLDSIG11]specification. If present then any certificate chain SHOULD
be validated and any CRL or OCSP information may be used as
appropriate [RFC5280]..
I suggest we could also adopt your text by changing the final sentence
above to
If present then user agents MUST perform Basic Path
Validation [RFC 5280] on the signing key and SHOULD perform revocation
checking as appropriate. The set of acceptable
trust anchors, and policy decisions based on the signer's identity
are established through a security-critical out-of-band mechanism.
Question:
Should re require use of X509Data to convey certificates?
I was suggesting not, since this could be conveyed out of band and it
might not always be appropriate to include in every signature.
Thoughts on this one?
regards, Frederick
Frederick Hirsch
Nokia
On Feb 25, 2009, at 9:23 AM, ext Thomas Roessler wrote:
I propose that we add te following text in the beginning of 6.2:
The validation procedure given in this section describes extensions
to XML Signature Core Validation. In addition to the steps defined
in these two specifications, user agents MUST perform Basic Path
Validation [RFC 5280] on the signing key. The set of acceptable
trust anchors, and policy decisions based on the signer's identity
are established through a security-cirtical out-of-band mechanism.
(If somebody can think of something nicer to say, that's fine as
well. Note that the Basic Path Validation requirement isn't really
new -- it's implicit to our use of X.509, if done properly.
Nevertheless, worth calling out properly.)
--
Thomas Roessler, W3C <[email protected]>
