W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

RE: xmldsig questions

From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
Date: Mon, 20 Dec 1999 19:52:14 -0800
Message-ID: <4992824A0863D211964B0008C7B1ACB803E1BBE0@fifi.platinum.corp.microsoft.com>
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>

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

Received on Monday, 20 December 1999 23:02:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC