ietf-smime
[Top] [All Lists]

RE: Use of attribute certificates in SignedData

2001-08-29 11:57:09
I found a comment in my code:
 
        // REVIEW: This will puke on Attribute Certificates and PKCS #6
certs!

Blake
-----Original Message-----
From: Christopher S. Francis 
[mailto:chris(_dot_)francis(_at_)wetstonetech(_dot_)com]
Sent: Tuesday, August 28, 2001 2:29 PM
To: ietf-smime(_at_)imc(_dot_)org; Pawling, John
Subject: RE: Use of attribute certificates in SignedData


John,
 
Understood.  So I'm interpreting RFC-2630 correctly then.  When I said I was
considering putting the AC in the 'certificates' field, I really meant that
I wanted to include it as an attrCert choice in the 'certificates' field. 
 
So if that's the "correct" place to put the AC according to 2630, what
experience have people had with real-world applications that process
SignedData?  Will applications/toolkits that understand how to verify the
signature on SignedData, but do not process ACs typically just ignore the AC
if it's included or do they choke because: 1) they can't successfully decode
the AC or 2) they can't successfully validate the AC?
 
Ideally, I'd like to make the AC available for applications that are capable
of using it and have applications that are not AC-enabled just ignore it and
verify the signature on the SignedData using the PKC.  In the description of
the 'certificates' field, RFC-2630 says the following regarding the
certificates in the set: "There may be more certificates than necessary, and
there may be certificates sufficient to contain chains from two or more
independent top-level certification authorities."  This seems to *imply*
that compliant, but AC challenged applications will just ignore the AC as
long as they can validate the signature using the PKC.  I'm just looking for
a bit of a reality check.  Is that the way it works in the real world?
 
Thanks for the heads up regarding the fact that CMS specifies the 1997 X.509
syntax.  I'll go do some reading on what the differences are.  Depending on
the answers to the questions above, it may not matter though.  We're writing
our own X.509 2000 compliant application to process the ACs.  At this point,
it's probably acceptable to say that other third-party AC-enabled
applications must support X.509 2000 to process our SignedData blob.  As I
mentioned above, as long as commonly available 3rd party validation software
doesn't choke, it's ok if it ignores the AC.
 
Chris
 
-----Original Message-----
From: Pawling, John [mailto:John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com]
Sent: Tuesday, August 28, 2001 3:43 PM
To: 'Christopher S. Francis'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Use of attribute certificates in SignedData
 
Chris, 
RFC2630 specifies that an AttributeCertificate can be included in the
signedData certificates attrCert field.  Please note that RFC2630 specifies
the 1997 X.509 Attribute Certificate syntax (that is incompatible with the
2000 X.509 Attribute Certificate syntax).  Also, please note that RFC2630
states the following requirement regarding the value to be placed in the
signedData version field: "If attribute certificates are present, then the
value of version shall be 3."  
=========================================== 
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com 
Getronics Government Solutions, LLC 
=========================================== 
<Prev in Thread] Current Thread [Next in Thread>