ietf-smime
[Top] [All Lists]

Questions about PKCS #10 and cert extensions

1998-03-29 01:02:17
While making some long-overdue updates to the X.509 style guide, I saw that the
section on PKCS #10 use might need some corrections.  This currently says:
 
  According to the PKCS #10 spec, the attributes field is mandatory, so if it's
  empty it's encoded as a zero-length field.  The example however assumes that
  if there are no attributes, the field shouldn't be present, treating it like
  an OPTIONAL field.  A number of vendors conform to the example rather than
  the specification, but just to confuse the issue RSADSI, who produced PKCS
  #10, regard things the other way around, with the spec being right and the
  example being wrong.  The most obvious effect of this is that TIPEM (which
  was the only available toolkit for PKCS#10 for a long time) follows the spec
  and does it "wrong (sense #2)", whereas more recent independant
  implementations follow the example and do it "wrong (sense #1)".
 
  PKCS #10 also dates from the days of X.509v1 and includes references to
  obsolete and deprecated objects and data formats.  PKCS #6 extended
  certificates are a workaround for the abscence of certificate extensions in
  X.509v1 and shouldn't be used at all, and it's probably a good idea to avoid
  the use of PKCS #9 extended attributes as well (some certification request
  protocols bypass the use of PKCS #9 by wrapping extra protocol layers
  containing PKCS #9 elements around the outside of PKCS #10).  Unfortunately
  since PKCS #10 doesn't mention X.509v3 at all, there's no clear indication of
  what is and isn't valid as an attribute for X.509v3 (for example a
  GeneralName should be treated as a valid attribute, a BasicConstraint may or
  may not be treated as valid depending on the CA's certification policy, and
  an AuthorityKeyIdentifier would definitely be an invalid attribute).
 
  To add to the confusion, the S/MIME certificate request draft states that
  X.509v3 extensions used as attributes in a certification request should be
  encoded as a SEQUENCE OF extensions wrapped up in a PKCS #9 attribute
  identified by the OID { pkcs-9 14 }.
 
Unfortunately I haven't been able to find anything which clears up the
confusion over either the encoding of the attributes field, or the use of
X.509v3 extensions.  Is anyone aware of implementations which still encode the
attributes as if they were declared 'Attributes OPTIONAL'?  Everything I've
seen recently always encodes the attributes as a zero-length field, however
being outside the US I can't check what most of the commonly-available
implementations do.  Should I recommend that they always be encoded as per the
spec and drop the section on encoding as per the example entirely?  (NB: I know
what the official position on this is, what I'd like to know is what it's like
in practice).
 
The other area of confusion is what's in the attributes.  PKCS #10 still refers
to the deprecated PKCS #6 extended certificates, as well as PKCS #9 extended
attributes, but not X.509v3 attributes/extensions which would probably be more
useful.  If I could get some indication of usage of X.509v3 attributes in a
certification request I'd like to add some comments on it to the guide -
because PKCS #10 predates the various v3 attributes you often have to resort to
guesswork to find out what is and isn't acceptable.  Are the comments in the
text above appropriate?  How should X.509v3 attributes be specified, as per the
S/MIME draft or directly as attributes (without the PKCS #9 wrapping)?  What
attributes are valid?  What ones are used in practice?
 
On the subject of extensions, the guide currently makes some rather vague
comments about handling extensions.  Looking through the X.509v3, S/MIME, and
PKIX cert-related drafts, I've noticed that the recommendations in there about
handling the critical flag are even more vague, since if the critical flag
isn't set most of the extensions are meant to be of an advisory nature only.
This means that an implementation could conceivably handle them with:
 
 1. If extension is critical and unrecognised, cert = invalid.
 2. If extension is noncritical, ignore it.
 
which relegates all noncritical extensions to communicating the message "I'm
only including this to bloat up the cert" (very few of the certs I've got have
their extensions marked as critical, in playing with MSIE and Netscape I've
found that doing this renders some certs unusable by both browsers).  For
instance consider the <anonymous CA> root cert, which is marked, via a keyUsage
extension, as being for cert and CRL signing only.  Since it's non-critical,
I'm free to ignore this and use it for key exchange, encryption, and whatever
else I please.
 
The problem lies in the nature of the critical flag (and I know this has been
debated before, but it was never really resolved).  At the moment it's used as:
 
 Critical = you must process this extension
 Non-critical = you don't have to process this extension
 
However "you don't have to process this extension" leaves implementors free to
either process it anyway or ignore it.  What complicates this issue is that
various standards leave the question of criticality up to implementors ("it
would be cool if you made this critical, but don't like, feel any pressure to
do so", or words to that effect).  Since including certain extensions like
basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
unless they're marked critical, I'm thinking of recommending that if used,
these extensions must be marked critical.  What do people think about this?
 
Peter.
 


<Prev in Thread] Current Thread [Next in Thread>
  • Questions about PKCS #10 and cert extensions, Peter Gutmann <=