- From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
- Date: Mon, 20 Dec 1999 19:52:14 -0800
- To: "'Joseph M. Reagle Jr.'" <reagle@w3.org>, Frederick Hirsch <hirschf@certco.com>
- Cc: w3c-ietf-xmldsig@w3.org, John Boyer <jboyer@uwi.com>, David Solo <david.solo@citicorp.com>
- Message-ID: <4992824A0863D211964B0008C7B1ACB803E1BBE0@fifi.platinum.corp.microsoft.com>
Frederick: Clarifications on X.509 certificates included as KeyInfo: >2. For KeyInfo, KeyData, Is it correct to assume a CERTIFICATE element >for each certificate in the signing party certificate chain? Is it >correct to specify the encoding for each as an attribute of the >certificate element? David, Barbara, others? (Barb) X509Data contains an identifier for the key or cert used to validate a signature. These can be a certificate, a bunch of certificates or identifiers like IssuerSerial, subject name, etc. We do not make any assumptions about what collections of X509Data might be. >3. I assume that X.509 oids are not used since they are implicit in an >XML element. Thus for example, if the signer sends device specific >information as part of signing, the OID for this information would be >implicit. Thus if in ASN.1 it is AUTHINFO and an OID, the tag >SignerDeviceInfo would be enough - if the recipient knows to map this >to the OID. (I guess I'm asking and assuming OID mapping is >application dependent). David, Barbara, others? (Barb) Your statement is correct - sort of. OIDs in ASN.1 define a de-codable structure that in turn, defines processing rules/semantics. In XML, you don't need an OID as a parse hint for the bytes that follow it because you can parse the XML directly. The important point is that the processing/semantic meaning for an XMLDSIG doc can change on the fly. >4. In section 3.4, KeyInfo, I note that the spec allows including a >CRL, with element X509CRL. Can we also define including signed OCSP >responses, with an X509OCSP element? This would allow transmitted the >status of the certs with a transaction in an interoperable manner. David, Barbara, others? (Barb) X509OCSP: This isn't a big deal to add, but it has the potential to open a can of snakes that we've carefully tried to avoid, "freshness of certificates." We don't require certificates in XML signatures. They're just one form of evidence that MAY be provided by a signer to a verifier. Attaching an OCSP response could be considered additional evidence. What we want to avoid tho is our making any implied recommendations about signers having to get and attach OCSP responses (or certs, for that matter) to their signed documents. An OCSP response in particular seems pretty silly since if a verifier wants freshness information about a certificate, he can get his own OCSP response. Barbara Fox Microsoft
Received on Monday, 20 December 1999 23:02:57 UTC