On 20/12/12 11:48, Stephen Farrell wrote:
<snip>
We mean what we say: ASN.1 NULL data.
What would you like us to fix?
Explicitly say that the ASN.1 NULL (0x05 0x00) is the
value of the OCTET STRING. People have gotten NULL messed up
before like that, mainly in AlgorithmIdentifier, but quite
a few did it. They assumed because it said "NULL" that meant
that nothing is put into the DER encoding. That breaks
interop.
In case it helps...
I just looked at RFC5280 and its predecessors for inspiration on how
best to specify the syntax of certificate extensions.
RFC2459 says stuff like...
id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19}
basicConstraints EXTENSION ::= {
SYNTAX BasicConstraintsSyntax
IDENTIFIED BY id-ce-basicConstraints }
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
...but RFC3280 and RFC5280 replaced the EXTENSION definitions with
comments...
-- basic constraints extension OID and syntax
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
Now in this case, since you're trying to deliberately break
interop for those precerts you could defend the ambiguity
I guess, but it makes me hold my nose even so;-)
S.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
