Re: Issuer field in the CRL should be byte-for-byte equivalent with that in cert

[Kathleen Wilson]

On Friday, February 3, 2017 at 7:26:14 AM UTC-8, Jakob Bohm wrote:
> 
> No, I am suggesting that while *still* listing it as a problematic
> practice for an edge case from a few few CAs, Mozilla offers those few
> CAs an easier way out, while at the same time obtaining for both itself
> and any other implementors (such as Google's BoringSSL and Microsoft's
> CNG) a table of the only values that code for that edge case will need
> to handle.
> 
> I was also suggesting, that if, after gathering data, the resulting
> table is very small, using the table in code might be easier than
> coding an algorithm that matches certificates to issuers and CRLs for
> all the needed non-identical cases.  This however would be an
> implementation choice, as any other algorithm giving correct results
> would solve the problem.
>


There is a bug to "Make OneCRL name comparisons encoding agnostic"...
https://bugzilla.mozilla.org/show_bug.cgi?id=1330968

But we'll still call it out as a problematic practice.

Cheers,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Issuer field in the CRL should be byte-for-byte equivalent with that in cert

[Jakob Bohm]

On 03/02/2017 14:30, Ryan Sleevi wrote:

On Thu, Feb 2, 2017 at 9:37 PM Jakob Bohm  wrote:


On 03/02/2017 05:22, Ryan Sleevi wrote:

On Thu, Feb 2, 2017 at 3:59 PM, Jakob Bohm 

wrote:



On 02/02/2017 00:46, Kathleen Wilson wrote:


All,

I've added another Potentially Problematic Practice, as follows.



https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL

The encoding of the Issuer field in the CRL should be byte-for-byte
equivalent with the encoding of the Issuer in the certificate; that is,
using the exact same string types and field contents. The specs (RFC

2459,

RFC 3280, RFC 5280) permit them to mismatch, but that causes

compatibility

issues with various clients -- in such cases client software might not

find

the entry for the revoked certificate in the CRL.

As always, I will appreciate your thoughtful and constructive feedback.

We ran into this situation several times while adding entries to OneCRL
for revoked intermediate certificates, because our script pulled the

data

from the CAs' CRLs where possible.

We have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1330968 to
update the OneCRL client to be encoding agnostic when doing the Issuer
comparisons.



What should a CA do if they have used different encodings of the same
issuer DN in different certs that point to the same CRL location?

Wouldn't a more proper set of rules be:

1. The encoding of the Issuer field in the CRL must be the same as in
  the SubjectDN in the issuing certificate.

2. The IssuerDN in all future issued certificates must the same as in
  the SubjectDN in the issuing certificate.

3. If any previously issued certificates did not follow rule 2, the CA
  must publish a list of the exact IssuerDN encodings used in such
  certificates.



What value does 3 provide?



It provides data to allow services such as OneCRL (or even direct CRL
checking code in applications) to work around such past practices by
simply using a table of known Issuer name in certificate to actual
subject name in issuing certificate mappings, rather than trying to
implement fuzzy matching algorithms.



So don't you think it's useful and important to state the goal you're
trying to achieve when you propose Mozilla be prescriptive of all CAs?


The stated goal was to be *less* onerous than Kathleens proposal, which
was the the CRL issuer DN should be encoded exactly as it is in *every*
certificate referring to that issuer.

For the majority of CAs where this was always the case, neither
requirement would do involve any action at all.  For the cases where a
CA has in the past issued certificates and CRLs with different IssuerDN
encoding, but has done so consistently, my proposal would allow the CA
to end its problematic practice without having to roll a new
intermediary CA with a different CRL service URL.

For the third case (which may or may not be as common as the second
one) where a CA has in the past issued certificates and CRLs with
different IssuerDN encoding, but has already mended its ways so more
recently issued certificates have the same IssuerDN encoding as in the
CAcert and CRL, the original proposal would have required *the same
CRL* to contain two conflicting IssuerDN encodings while my proposal
would allow such a CA to simply make a public statement that this is
the situation (with some specific details) and then continue.



Put differently, there is a considerably high bar for requiring CAs take
some action - or answer a particular question. Making sure it's clear why
can help evaluate the value of what you propose, otherwise it's very easy
to dismiss such suggestions as random non sequitors.



The data is minimal and compact, unlike CT logs.



For example, this appears as a nonsequitor, because no one has proposed
sending CT logs to clients (the contextual way to read this suggestion,
given the statement that follows). Another way to read it (ignoring what
follows) suggests perhaps confusion between a CT log (which clients don't
download) and an SCT (which is minimal and compact for what it is). Or it
could be read that you're suggesting someone simply comb the CT logs,
extract the CRL URLs, and compare those against the issuer fields present.


I was indeed suggesting the impracticality of both these causes of
action.



While it seems highly unlikely you're proposing the last option, given your
expressed disdain and occasional confusion about CT, I mention it because
it's example of where the data can be independently obtained, rather than
using the threat of force (which is, implicitly, what is behind every CA
communication - the threat of removal), and arguably in a way that more
accurately captures practical impact.

The complete dataset

from all public CAs combined is likely to be just a few kilobytes
uncompressed, much less compressed.





Potentially, this same table as a substitute for fuzzy mapping can also
be used when building/following 

Re: Issuer field in the CRL should be byte-for-byte equivalent with that in cert

[Ryan Sleevi]

On Thu, Feb 2, 2017 at 9:37 PM Jakob Bohm  wrote:

> On 03/02/2017 05:22, Ryan Sleevi wrote:
> > On Thu, Feb 2, 2017 at 3:59 PM, Jakob Bohm 
> wrote:
> >
> >> On 02/02/2017 00:46, Kathleen Wilson wrote:
> >>
> >>> All,
> >>>
> >>> I've added another Potentially Problematic Practice, as follows.
> >>>
> >>>
> https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL
> >>> The encoding of the Issuer field in the CRL should be byte-for-byte
> >>> equivalent with the encoding of the Issuer in the certificate; that is,
> >>> using the exact same string types and field contents. The specs (RFC
> 2459,
> >>> RFC 3280, RFC 5280) permit them to mismatch, but that causes
> compatibility
> >>> issues with various clients -- in such cases client software might not
> find
> >>> the entry for the revoked certificate in the CRL.
> >>>
> >>> As always, I will appreciate your thoughtful and constructive feedback.
> >>>
> >>> We ran into this situation several times while adding entries to OneCRL
> >>> for revoked intermediate certificates, because our script pulled the
> data
> >>> from the CAs' CRLs where possible.
> >>>
> >>> We have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1330968 to
> >>> update the OneCRL client to be encoding agnostic when doing the Issuer
> >>> comparisons.
> >>>
> >>>
> >> What should a CA do if they have used different encodings of the same
> >> issuer DN in different certs that point to the same CRL location?
> >>
> >> Wouldn't a more proper set of rules be:
> >>
> >> 1. The encoding of the Issuer field in the CRL must be the same as in
> >>   the SubjectDN in the issuing certificate.
> >>
> >> 2. The IssuerDN in all future issued certificates must the same as in
> >>   the SubjectDN in the issuing certificate.
> >>
> >> 3. If any previously issued certificates did not follow rule 2, the CA
> >>   must publish a list of the exact IssuerDN encodings used in such
> >>   certificates.
> >>
> >
> > What value does 3 provide?
> >
>
> It provides data to allow services such as OneCRL (or even direct CRL
> checking code in applications) to work around such past practices by
> simply using a table of known Issuer name in certificate to actual
> subject name in issuing certificate mappings, rather than trying to
> implement fuzzy matching algorithms.


So don't you think it's useful and important to state the goal you're
trying to achieve when you propose Mozilla be prescriptive of all CAs?

Put differently, there is a considerably high bar for requiring CAs take
some action - or answer a particular question. Making sure it's clear why
can help evaluate the value of what you propose, otherwise it's very easy
to dismiss such suggestions as random non sequitors.

>
> The data is minimal and compact, unlike CT logs.


For example, this appears as a nonsequitor, because no one has proposed
sending CT logs to clients (the contextual way to read this suggestion,
given the statement that follows). Another way to read it (ignoring what
follows) suggests perhaps confusion between a CT log (which clients don't
download) and an SCT (which is minimal and compact for what it is). Or it
could be read that you're suggesting someone simply comb the CT logs,
extract the CRL URLs, and compare those against the issuer fields present.

While it seems highly unlikely you're proposing the last option, given your
expressed disdain and occasional confusion about CT, I mention it because
it's example of where the data can be independently obtained, rather than
using the threat of force (which is, implicitly, what is behind every CA
communication - the threat of removal), and arguably in a way that more
accurately captures practical impact.

The complete dataset
> from all public CAs combined is likely to be just a few kilobytes
> uncompressed, much less compressed.


>
> Potentially, this same table as a substitute for fuzzy mapping can also
> be used when building/following certificate chains.


Right, so just to follow:

You're proposing that, rather than list it as a problematic practice for an
edge case from a few CAs, Mozilla use a CA communication - possibly with a
change to the Baseline Requirements - so that they can write additional
code that no other client implements and ship several kilobytes (at least)
of data and code.

It does seem like Kathleen's current proposal is far more reasonable, and
so no, your proposal does not seem like a proper set of rules.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Issuer field in the CRL should be byte-for-byte equivalent with that in cert

[Jakob Bohm]

On 03/02/2017 05:22, Ryan Sleevi wrote:

On Thu, Feb 2, 2017 at 3:59 PM, Jakob Bohm  wrote:


On 02/02/2017 00:46, Kathleen Wilson wrote:


All,

I've added another Potentially Problematic Practice, as follows.

https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL
The encoding of the Issuer field in the CRL should be byte-for-byte
equivalent with the encoding of the Issuer in the certificate; that is,
using the exact same string types and field contents. The specs (RFC 2459,
RFC 3280, RFC 5280) permit them to mismatch, but that causes compatibility
issues with various clients -- in such cases client software might not find
the entry for the revoked certificate in the CRL.

As always, I will appreciate your thoughtful and constructive feedback.

We ran into this situation several times while adding entries to OneCRL
for revoked intermediate certificates, because our script pulled the data
from the CAs' CRLs where possible.

We have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1330968 to
update the OneCRL client to be encoding agnostic when doing the Issuer
comparisons.



What should a CA do if they have used different encodings of the same
issuer DN in different certs that point to the same CRL location?

Wouldn't a more proper set of rules be:

1. The encoding of the Issuer field in the CRL must be the same as in
  the SubjectDN in the issuing certificate.

2. The IssuerDN in all future issued certificates must the same as in
  the SubjectDN in the issuing certificate.

3. If any previously issued certificates did not follow rule 2, the CA
  must publish a list of the exact IssuerDN encodings used in such
  certificates.



What value does 3 provide?



It provides data to allow services such as OneCRL (or even direct CRL
checking code in applications) to work around such past practices by
simply using a table of known Issuer name in certificate to actual
subject name in issuing certificate mappings, rather than trying to
implement fuzzy matching algorithms.

The data is minimal and compact, unlike CT logs.  The complete dataset
from all public CAs combined is likely to be just a few kilobytes
uncompressed, much less compressed.

Potentially, this same table as a substitute for fuzzy mapping can also
be used when building/following certificate chains.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Issuer field in the CRL should be byte-for-byte equivalent with that in cert

[Jakob Bohm]

On 02/02/2017 00:46, Kathleen Wilson wrote:

All,

I've added another Potentially Problematic Practice, as follows.

https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL
The encoding of the Issuer field in the CRL should be byte-for-byte equivalent 
with the encoding of the Issuer in the certificate; that is, using the exact 
same string types and field contents. The specs (RFC 2459, RFC 3280, RFC 5280) 
permit them to mismatch, but that causes compatibility issues with various 
clients -- in such cases client software might not find the entry for the 
revoked certificate in the CRL.

As always, I will appreciate your thoughtful and constructive feedback.

We ran into this situation several times while adding entries to OneCRL for 
revoked intermediate certificates, because our script pulled the data from the 
CAs' CRLs where possible.

We have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1330968 to update 
the OneCRL client to be encoding agnostic when doing the Issuer comparisons.



What should a CA do if they have used different encodings of the same
issuer DN in different certs that point to the same CRL location?

Wouldn't a more proper set of rules be:

1. The encoding of the Issuer field in the CRL must be the same as in
  the SubjectDN in the issuing certificate.

2. The IssuerDN in all future issued certificates must the same as in
  the SubjectDN in the issuing certificate.

3. If any previously issued certificates did not follow rule 2, the CA
  must publish a list of the exact IssuerDN encodings used in such
  certificates.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy