Hi Rob, all,
last consideration about the I-D - there are a bunch of OID values that
are used throughout the document that are using PRIVATE (Google) OIDs in
the document - this is *completely wrong*! Private OIDs should not be
used for I-Ds.
The authors should request a new OID assigned for trans under (most
probably) the id-pkix OID and then define the required OIDs in that
space. This should also be reflected, I think, in the IANA consideration
section.
For example:
id-trans OBJECT IDENTIFIER ::= { id-pkix XX }
id-trans-xxxx OBJECT IDENTIFIER ::= { id-trans 1 }
...
Cheers,
Max
P.S.: Cross posting this message to the TRANS ml so that the WG can
consider these issues in the I-D.
On 3/27/15 12:44 PM, Massimiliano Pala wrote:
Hi Rob, all,
coming to your question: the extension /*will not break compatibility
as long as it is not marked critical*/. However, there might be some
aspects you want to think a bit more deeply about before taking a
decision.
This said, I think that the text written in section 3.4.2 is wrong and
needs to be replaced.
In particular, the argument about the encoding is weird - from the I-D:
One or more SCTs can be embedded in an X.509v3 extension that is
included in a certificate or an OCSP response. Since RFC5280
requires the "extnValue" field (an OCTET STRING) of each X.509v3
extension to include the DER encoding of an ASN.1 value, we cannot
embed a "SignedCertificateTimestampList" directly. Instead, we
have
to wrap it inside an additional OCTET STRING (see below), which we
then put into the "extnValue" field.
In my opinion, this text should be removed (trying to justify the use
of a data type in the encoding because you do not want to define the
required structure in ASN.1 does not really look.. good in an I-D, I
am surprised it is even there).
However, more considerations are required here. If you want the
extension to have a non-ASN.1 structure it is fine, but that will have
implication over the (format) compliance of data in the certificate.
This was marginally mentioned in previous posts, but it seems it
requires a more explicit explanation since it was not well understood.
In particular, from a parsing perspective, when using the proposed
encoding, the client will not perform any validation over the contents
of the extension since this is just a blob. Usually this type of
encoding is used for binary contents that have no internal structure
(e.g., a value of a key or a digest), but it is usually avoided for
complex types (again, to provide format validation of the contents).
The real question here is: are you willing to live with not validating
the format of the content of the extension when the extension is
actually parsed? Are you considering the possible attack vectors that
can derive from that (i.e. allowing custom contents in the extension)?
I hope you already discussed these aspects before proposing the
extension. If not, my suggestion is to go back to the drawing board
and seriously considering these aspects. If you go ahead with the
current choice, I would suggest to remove the 3.4.2 text and add some
considerations about it in the security considerations section
(although, in that case I would STRONGLY suggest to revisit your choice).
This is usually a good rule of thumb when it comes to adding extensions.
Another operational consideration that was pointed out is about
debugging the bits on the wire. If you use ASN.1 structures, standard
network tools can parse the extension properly - however, again, this
will not be the case for OCTET STRING blobs. Thus, debugging of the
extension (in case of issues) can only happen at the end points (where
the extension parser is available), not on the wire.
I hope this helps clarifying the issues with the current proposal.
Just my 2 cents.
Cheers,
Max
On 3/25/15 9:44 AM, Rob Stradling wrote:
On 25/03/15 14:20, Sean Leonard wrote:
On Mar 18, 2015, at 2:10 AM, Peter Gutmann
<[email protected]> wrote:
Melinda Shore <[email protected]> writes:
it's what's in the document until someone can either point to some
normative
specification that it violates or can point to something that
actually would
break.
This isn't a case of standards rules-lawyering though (in any case
the PKIX
spec is flexible enough that you can stuff anything you want into a
certificate if you interpret things just right, see the famous
MPEG-of-cat
quote), it's that this is creating a situation where an *X.509
standards-
compliant certificate* contains data that can't be processed by an
*X.509
standards-compliant certificate application*.
I agree with Peter. Keep the encoding as ASN.1 for this extension.
It is not particularly onerous, and it preserves compatibility for
other applications.
How exactly might the certificate extension we're talking about [1]
break compatibility with other applications?
The Subject Key Identifier extension uses the exact same ASN.1 syntax
(the content of the extension is a plain OCTET STRING). RFC5280 does
not require applications to recognize this extension.
I'm not aware of any applications that choke on the Subject Key
Identifier extension, so why should we expect any to choke on the
6962-bis extension?
[1]
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/?include_text=1
Sections 3.4.2 and 3.4.2.2
_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
